From jeroen@unfix.org Fri Nov 1 00:40:31 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 1 Nov 2002 01:40:31 +0100 Subject: [6bone] Bizarre problems in freebsd. In-Reply-To: <3DC1BB7B.8C5A4A2C@fpsn.net> Message-ID: <000a01c2813f$4884a310$420d640a@unfix.org> Colin Faber wrote: > Hi folks, > > One of my freebsd machines seems to be having problems with it's ipv6 > setup. The problem is that from some of the machines on my network I > can't ping the freebsd box until it starts to ping the machine which > is trying to ping it. Ping/Connect etc. > > Any ways the one MS box I have on the network can't really > seem to talk > to it at all even though all machines can talk to any other machine. > > Any suggestions on trouble shooting? You might start by giving a detailed listing of OS's and version numbers, routing tables, interface configurations etc. We know only know that you are trying to ping "IPv6 hosts" concerning at least 1 freebsd box and 1 windows box. Greets, Jeroen From basit@basit.cc Fri Nov 1 09:51:32 2002 From: basit@basit.cc (Abdul Basit) Date: Fri, 1 Nov 2002 03:51:32 -0600 (CST) Subject: [6bone] Bizarre problems in freebsd. In-Reply-To: <000a01c2813f$4884a310$420d640a@unfix.org> Message-ID: also tcpdump dumps will certainly help on both sides - basit On Fri, 1 Nov 2002, Jeroen Massar wrote: > Colin Faber wrote: > > > Hi folks, > > > > One of my freebsd machines seems to be having problems with it's ipv6 > > setup. The problem is that from some of the machines on my network I > > can't ping the freebsd box until it starts to ping the machine which > > is trying to ping it. Ping/Connect etc. > > > > Any ways the one MS box I have on the network can't really > > seem to talk > > to it at all even though all machines can talk to any other machine. > > > > Any suggestions on trouble shooting? > > You might start by giving a detailed listing of OS's and version > numbers, routing tables, interface configurations etc. > We know only know that you are trying to ping "IPv6 hosts" concerning at > least 1 freebsd box and 1 windows box. > > Greets, > Jeroen > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From itojun@iijlab.net Fri Nov 1 04:47:56 2002 From: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Fri, 01 Nov 2002 13:47:56 +0900 Subject: [6bone] Bizarre problems in freebsd. In-Reply-To: cfaber's message of Thu, 31 Oct 2002 16:23:39 MST. <3DC1BB7B.8C5A4A2C@fpsn.net> Message-ID: <20021101044756.2304A7B9@starfruit.itojun.org> >Hi folks, > > One of my freebsd machines seems to be having problems with it's ipv6 >setup. The problem is that from some of the machines on my network I >can't ping the freebsd box until it starts to ping the machine which >is trying to ping it. Ping/Connect etc. > >Any ways the one MS box I have on the network can't really seem to talk >to it at all even though all machines can talk to any other machine. > >Any suggestions on trouble shooting? it is likely that you have multicast breakage on some of your boxes. itojun From enric@satec.es Sun Nov 3 21:18:44 2002 From: enric@satec.es (Enric Corominas i Bosch) Date: Sun, 03 Nov 2002 22:18:44 +0100 Subject: [6bone] Problem with Autoconfiguration when using 802.1Q encapsulation Message-ID: <200211032218440900.00A9890E@mail.satec.es> Dear All, I'm trying to configure a Debian host as an IPv6 firewall. I have just one ethernet card, so I've been playing with 802.1Q, configuring three let's call "subinterfaces". I use the software from candelatech (http://www.candelatech.com/~greear/vlan.html) to create the subinterfaces, and everything seems to work fine, the interfaces creates link local addresses, they are recognized by the switch, and the communication is fine. Also I can give the subinterfaces an IPv6 address, and announce it with "radvd" (latest version, 0.7.2). >=======================================> almodis:/home/enric/vlan/vlan# ifconfig eth0 Link encap:Ethernet HWaddr 00:00:E8:79:C0:43 inet6 addr: fe80::200:e8ff:fe79:c043/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:140467 errors:0 dropped:0 overruns:0 frame:0 TX packets:6546 errors:36 dropped:0 overruns:0 carrier:72 collisions:623 txqueuelen:100 RX bytes:10607455 (10.1 MiB) TX bytes:1022885 (998.9 KiB) Interrupt:5 Base address:0xe400 eth0.2 Link encap:Ethernet HWaddr 00:00:E8:79:C0:43 inet addr:213.164.61.200 Bcast:213.164.61.255 Mask:255.255.255.192 inet6 addr: fe80::200:e8ff:fe79:c043/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:36645 errors:0 dropped:0 overruns:0 frame:0 TX packets:6497 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3711593 (3.5 MiB) TX bytes:1002537 (979.0 KiB) >=======================================> But I've detected that the interface is not able to autoconfigure when receiving an "Router Advertisement" The RA is received correctly, but is ignored. >=======================================> Router advertisement from fe80::230:94ff:fe0a:b420 (hoplimit 255) Received by interface eth0.2 # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvCurHopLimit: 64 AdvManagedFlag: off AdvOtherConfigFlag: off AdvHomeAgentFlag: off AdvReachableTime: 0 AdvRetransTimer: 0 AdvSourceLLAddress: 00 30 94 0A B4 20 Prefix 3ffe:400a:0:803::/64 AdvValidLifetime: 2592000 AdvPreferredLifetime: 604800 AdvOnLink: on AdvAutonomous: on AdvRouterAddr: off >=======================================> I have looked into "/proc/sys/net/ipv6/conf/eth0.2", and "accept_ra" is set to "1", it is TRUE, so it should autoconfigure to the received prefix. If I try to set the value to "1" or "0" by hand using "sysctl", it gives a syntax error, as it seems not to recognize the "." in the name of the interface, changing it for a "/" >=======================================> almodis:/proc/net# sysctl -w net/ipv6/conf/eth0.2/accept_ra=1 error: 'net/ipv6/conf/eth0/2/accept_ra' is an unknown key almodis:/proc/net# >=======================================> This make me think of a kind of bug, but I can't imagine how to resolve it. Another point I have seen is that the LINK LOCAL address has the same value in both "eth0" and "eth0.2", I don't know if this can have any relation with the ignoring of the router advertisement. Any one has tried a similar configuration ? Any ideas ? Thanks in advance, Enric Corominas i Bosch **************************************************************** Enric Corominas i Bosch enric@satec.es Network Engineer Satec S.A http://www.satec.es Edif. TESTA Sant Cugat Mòdul A, Planta 1 Tlf: +34 93 581 67 00 C/Alcalde Barnils, 64-68 Fax:+34 93 581 67 01 Sant Cugat del Valles 08190 BARCELONA **************************************************************** From nicolas.deffayet@ndsoftware.net Sun Nov 3 22:31:59 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 03 Nov 2002 23:31:59 +0100 Subject: [6bone] Problem with Autoconfiguration when using 802.1Q encapsulation In-Reply-To: <200211032218440900.00A9890E@mail.satec.es> References: <200211032218440900.00A9890E@mail.satec.es> Message-ID: <1036362719.16733.4583.camel@wks1.fr.corp.ndsoftware.com> On Sun, 2002-11-03 at 22:18, Enric Corominas i Bosch wrote: Dear Enric, > I'm trying to configure a Debian host as an IPv6 firewall. I have just one ethernet card, so I've been playing with > 802.1Q, configuring three let's call "subinterfaces". > > I use the software from candelatech (http://www.candelatech.com/~greear/vlan.html) to create the subinterfaces, and everything seems to work fine, the interfaces creates link local addresses, they are recognized by the switch, and the communication is fine. > > Also I can give the subinterfaces an IPv6 address, and announce it with "radvd" (latest version, 0.7.2). > > >=======================================> > almodis:/home/enric/vlan/vlan# ifconfig > eth0 Link encap:Ethernet HWaddr 00:00:E8:79:C0:43 > inet6 addr: fe80::200:e8ff:fe79:c043/10 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:140467 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6546 errors:36 dropped:0 overruns:0 carrier:72 > collisions:623 txqueuelen:100 > RX bytes:10607455 (10.1 MiB) TX bytes:1022885 (998.9 KiB) > Interrupt:5 Base address:0xe400 > > eth0.2 Link encap:Ethernet HWaddr 00:00:E8:79:C0:43 > inet addr:213.164.61.200 Bcast:213.164.61.255 Mask:255.255.255.192 > inet6 addr: fe80::200:e8ff:fe79:c043/10 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:36645 errors:0 dropped:0 overruns:0 frame:0 > TX packets:6497 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:3711593 (3.5 MiB) TX bytes:1002537 (979.0 KiB) > >=======================================> > > > But I've detected that the interface is not able to autoconfigure when receiving an "Router Advertisement" > The RA is received correctly, but is ignored. > > > >=======================================> > Router advertisement from fe80::230:94ff:fe0a:b420 (hoplimit 255) > Received by interface eth0.2 > # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump > AdvCurHopLimit: 64 > AdvManagedFlag: off > AdvOtherConfigFlag: off > AdvHomeAgentFlag: off > AdvReachableTime: 0 > AdvRetransTimer: 0 > AdvSourceLLAddress: 00 30 94 0A B4 20 > Prefix 3ffe:400a:0:803::/64 > AdvValidLifetime: 2592000 > AdvPreferredLifetime: 604800 > AdvOnLink: on > AdvAutonomous: on > AdvRouterAddr: off > >=======================================> > > > I have looked into "/proc/sys/net/ipv6/conf/eth0.2", and "accept_ra" is set to "1", it is TRUE, so it should autoconfigure to the received prefix. > > If I try to set the value to "1" or "0" by hand using "sysctl", it gives a syntax error, as it seems not to recognize the "." in the name of the interface, changing it for a "/" > > > >=======================================> > almodis:/proc/net# sysctl -w net/ipv6/conf/eth0.2/accept_ra=1 > error: 'net/ipv6/conf/eth0/2/accept_ra' is an unknown key > almodis:/proc/net# > >=======================================> > > This make me think of a kind of bug, but I can't imagine how to resolve it. > > Another point I have seen is that the LINK LOCAL address has the same value in both "eth0" and "eth0.2", I don't know if this can have any relation with the ignoring of the router advertisement. > > Any one has tried a similar configuration ? Any ideas ? Autoconfiguration don't work probably because you have 2 interfaces with the same MAC address. In the USAGI mailing-list (http://www2.linux-ipv6.org/ml/usagi-users/msg00832.html), YOSHIFUJI Hideaki wrote: "It seems that we should modify something to support IPv6." 802.1Q VLAN implementation for Linux need modification for support IPv6 ? Best Regards, Nicolas DEFFAYET From barce@frlp.utn.edu.ar Mon Nov 4 02:09:03 2002 From: barce@frlp.utn.edu.ar (Carlos Alberto Barcenilla) Date: Sun, 3 Nov 2002 23:09:03 -0300 Subject: [6bone] Problem with Autoconfiguration when using 802.1Qencapsulation References: <200211032218440900.00A9890E@mail.satec.es> <1036362719.16733.4583.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <000301c283af$cb040930$0100a8c0@america> Hi! I'm using 802.1q with ipv6 in linux routers (see http://www4.ipv6.frlp.utn.edu.ar) and address autoconfig works fine. I think the problem is that forwarding shoul be disabled in order to use stateless autoconfig, look at this example: [root@chuky conf]# ip -6 addr sh vlan3 6: vlan3: mtu 1500 qdisc noqueue inet6 fe80::250:bfff:fe1b:e026/10 scope link inet6 3ffe:38e1:200:3001::20/64 scope global [root@chuky conf]# echo 0 > /proc/sys/net/ipv6/conf/vlan3/forwarding A few seconds later vlan3 interface has a new autoconfigured address [root@chuky conf]# ip -6 addr sh vlan3 6: vlan3: mtu 1500 qdisc noqueue inet6 fe80::250:bfff:fe1b:e026/10 scope link inet6 3ffe:38e1:200:3001::20/64 scope global inet6 3ffe:38e1:200:3001:250:bfff:fe1b:e026/64 scope global dynamic valid_lft 2591994sec preferred_lft 604794sec Regards ----- Original Message ----- From: "Nicolas DEFFAYET" To: Cc: <6bone@ISI.EDU> Sent: Sunday, November 03, 2002 7:31 PM Subject: Re: [6bone] Problem with Autoconfiguration when using 802.1Qencapsulation > On Sun, 2002-11-03 at 22:18, Enric Corominas i Bosch wrote: > Dear Enric, > > > I'm trying to configure a Debian host as an IPv6 firewall. I have just one ethernet card, so I've been playing with > > 802.1Q, configuring three let's call "subinterfaces". > > > > I use the software from candelatech (http://www.candelatech.com/~greear/vlan.html) to create the subinterfaces, and everything seems to work fine, the interfaces creates link local addresses, they are recognized by the switch, and the communication is fine. > > > > Also I can give the subinterfaces an IPv6 address, and announce it with "radvd" (latest version, 0.7.2). > > > > >=======================================> > > almodis:/home/enric/vlan/vlan# ifconfig > > eth0 Link encap:Ethernet HWaddr 00:00:E8:79:C0:43 > > inet6 addr: fe80::200:e8ff:fe79:c043/10 Scope:Link > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:140467 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:6546 errors:36 dropped:0 overruns:0 carrier:72 > > collisions:623 txqueuelen:100 > > RX bytes:10607455 (10.1 MiB) TX bytes:1022885 (998.9 KiB) > > Interrupt:5 Base address:0xe400 > > > > eth0.2 Link encap:Ethernet HWaddr 00:00:E8:79:C0:43 > > inet addr:213.164.61.200 Bcast:213.164.61.255 Mask:255.255.255.192 > > inet6 addr: fe80::200:e8ff:fe79:c043/10 Scope:Link > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:36645 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:6497 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:0 > > RX bytes:3711593 (3.5 MiB) TX bytes:1002537 (979.0 KiB) > > >=======================================> > > > > > > But I've detected that the interface is not able to autoconfigure when receiving an "Router Advertisement" > > The RA is received correctly, but is ignored. > > > > > > >=======================================> > > Router advertisement from fe80::230:94ff:fe0a:b420 (hoplimit 255) > > Received by interface eth0.2 > > # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump > > AdvCurHopLimit: 64 > > AdvManagedFlag: off > > AdvOtherConfigFlag: off > > AdvHomeAgentFlag: off > > AdvReachableTime: 0 > > AdvRetransTimer: 0 > > AdvSourceLLAddress: 00 30 94 0A B4 20 > > Prefix 3ffe:400a:0:803::/64 > > AdvValidLifetime: 2592000 > > AdvPreferredLifetime: 604800 > > AdvOnLink: on > > AdvAutonomous: on > > AdvRouterAddr: off > > >=======================================> > > > > > > I have looked into "/proc/sys/net/ipv6/conf/eth0.2", and "accept_ra" is set to "1", it is TRUE, so it should autoconfigure to the received prefix. > > > > If I try to set the value to "1" or "0" by hand using "sysctl", it gives a syntax error, as it seems not to recognize the "." in the name of the interface, changing it for a "/" > > > > > > >=======================================> > > almodis:/proc/net# sysctl -w net/ipv6/conf/eth0.2/accept_ra=1 > > error: 'net/ipv6/conf/eth0/2/accept_ra' is an unknown key > > almodis:/proc/net# > > >=======================================> > > > > This make me think of a kind of bug, but I can't imagine how to resolve it. > > > > Another point I have seen is that the LINK LOCAL address has the same value in both "eth0" and "eth0.2", I don't know if this can have any relation with the ignoring of the router advertisement. > > > > Any one has tried a similar configuration ? Any ideas ? > > Autoconfiguration don't work probably because you have 2 interfaces with > the same MAC address. > > In the USAGI mailing-list > (http://www2.linux-ipv6.org/ml/usagi-users/msg00832.html), YOSHIFUJI > Hideaki wrote: > "It seems that we should modify something to support IPv6." > > 802.1Q VLAN implementation for Linux need modification for support IPv6 > ? > > > Best Regards, > > Nicolas DEFFAYET > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From cliff@oisec.net Mon Nov 4 06:18:37 2002 From: cliff@oisec.net (Cliff Albert) Date: Mon, 4 Nov 2002 07:18:37 +0100 Subject: [6bone] Problem with Autoconfiguration when using 802.1Q encapsulation In-Reply-To: <200211032218440900.00A9890E@mail.satec.es> References: <200211032218440900.00A9890E@mail.satec.es> Message-ID: <20021104061837.GA21258@oisec.net> On Sun, Nov 03, 2002 at 10:18:44PM +0100, Enric Corominas i Bosch wrote: > I'm trying to configure a Debian host as an IPv6 firewall. I have just one ethernet card, so I've been playing with > 802.1Q, configuring three let's call "subinterfaces". > > I use the software from candelatech (http://www.candelatech.com/~greear/vlan.html) to create the subinterfaces, and everything seems to work fine, the interfaces creates link local addresses, they are recognized by the switch, and the communication is fine. > > Also I can give the subinterfaces an IPv6 address, and announce it with "radvd" (latest version, 0.7.2). It should work, as we had it working on a 2.4.18 box with Debian and radvd. However the radvd package of debian needs a patch to support interfaces with a . (the flex parser doesn't recognize these as valid interfaces) However i haven't got that patch nearbye at the moment. I will put it somewhere this afternoon. -- Cliff Albert | RIPE: CA3348-RIPE | http://oisec.net/ cliff@oisec.net | 6BONE: CA2-6BONE | PGP Fingerprint = 9ED4 1372 5053 937E F59D B35F 06A1 CC43 9A9B 1C5A From jochen@scram.de Mon Nov 4 07:29:56 2002 From: jochen@scram.de (Jochen Friedrich) Date: Mon, 4 Nov 2002 08:29:56 +0100 (CET) Subject: [6bone] Problem with Autoconfiguration when using 802.1Qencapsulation In-Reply-To: <000301c283af$cb040930$0100a8c0@america> Message-ID: Hi Carlos, > I think the problem is that forwarding shoul be disabled in order to use > stateless autoconfig, look at this example: >From the kernel: if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra) { in6_dev_put(in6_dev); return; } Linux is definitely only accepting RAs, if both accept_ra is 1 and forwarding is 0 for a particular interface. --jochen From enric@satec.es Mon Nov 4 12:06:22 2002 From: enric@satec.es (Enric Corominas i Bosch) Date: Mon, 04 Nov 2002 13:06:22 +0100 Subject: [6bone] Problem with Autoconfiguration when using 802.1Qencapsulation In-Reply-To: References: Message-ID: <200211041306220700.0033E8D6@mail.satec.es> Hi all, Thanks for your answers, I've tested it and the problem was really on the "forwarding" set to "1", not in the VLAN operation. Enric From gert@space.net Mon Nov 4 16:33:47 2002 From: gert@space.net (Gert Doering) Date: Mon, 4 Nov 2002 17:33:47 +0100 Subject: [6bone] Who respect RFC2772 ? (4. Routing Policies for the 6bone) In-Reply-To: <1036060444.648.1948.camel@wks1.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Thu, Oct 31, 2002 at 11:34:04AM +0100 References: <1036060444.648.1948.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021104173346.L94537@Space.Net> Hi, while the thread itself is pretty ridiculous, it points out one important thing: On Thu, Oct 31, 2002 at 11:34:04AM +0100, Nicolas DEFFAYET wrote: > 4. Routing Policies for the 6bone [..] > AS15709 > 2001:650:10::/48 > > AS3327 > 2001:670:8B::/48 > > AS3561 > 2001:648:800::/48 > > AS818 > 2001:410:400::/40 All those networks (and all others that I have not quoted) do not use 6bone address space, and do not fall under the "6bone rules". So far, there are no universally accepted rules yet for announcement (or not) of more-specific prefixes from 2001:: space. Some think it's a good idea to overcome the multihoming issue, others stick to the "get an /48s from each upstream" paradigm, and yet others recommend to get an own sTLA for "important" multihomed networks. This isn't something which can be easily solved on *this* list, which is the 6bone-list and by convention doesn't really touch RIR space policy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48540 (48282) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From bmanning@beguile.ip4.int Tue Nov 5 01:53:26 2002 From: bmanning@beguile.ip4.int (bmanning@beguile.ip4.int) Date: Mon, 4 Nov 2002 17:53:26 -0800 Subject: [6bone] v6 recursive et.al. Message-ID: <20021104175326.B22513@vacation.ip4.int> the list: dot.ep.net. 1D IN AAAA 2001:478:6:0:230:48ff:fe22:6a29 dot.ep.net. 1D IN AAAA 3ffe:0:1:0:230:48ff:fe22:6a29 domreg.nic.ch. IN AAAA 2001:620:0:3:a00:20ff:fe85:9276 merapi.switch.ch. IN AAAA 2001:620:0:1:a00:20ff:fe88:a3f8 reva.sixgirls.org. 1H IN AAAA 3ffe:b80:133c:1::1 resns6.eurocyber.net. 1D IN CNAME koroth.muc.ipv6.eurocyber.net. koroth.muc.ipv6.eurocyber.net. 1D IN AAAA 2001:768:1:3::2 dns.pasta.cs.uit.no. 20M IN AAAA 2001:700:400:600::2 dns.pasta.cs.uit.no. 20M IN AAAA 2001:700:400:3001::2 shienar.ipv6.hiof.no. 1D IN AAAA 2001:700:a00:1::1 ns1.blazing.de. 10h40m IN AAAA 3ffe:2500:324:20:2a0:ccff:fe66:339b NL.linux.org. 1H IN AAAA 3ffe:8260:111:1::1 imladris.surriel.com. 1H IN AAAA 3ffe:8260:2000:1:210:5aff:fe47:4501 ns1.ipv6.lava.net. 2H IN AAAA 3ffe:8160::8 ns2.ipv6.lava.net. 2H IN AAAA 3ffe:8160::3 ns2.arch.bellsouth.net. 1H IN AAAA 3ffe:2900:3::3 imasd.ipv6.elmundo.es. 8H IN AAAA 2001:450:9:10::71 In our testbed, we recognize the following TLDs with v6 supported nameservers: JP, FR, INT, NL, COM, NET, ORG, CH, LI. To use the testbed (v6 enabled root servers), please return a signed copy of the following disclaimer to the following FAX: +1.310.322.8889 ---------------------------------------------------------------------------- ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; It has both IPv4 and IPv6 capable servers and is ; intended to test the capabilities of IPv6 native ; transport as well as DNSSEC capabilities. ; ; Copyright (c) 2001 by the University of Southern California ; Copyright (c) 2002 by the University of Southern California ; and EP.NET, LLC. ; All rights reserved ; ; Permission to use, copy, and distribute this data and its documentation ; for lawful non-commercial purposes and without fee is hereby granted, ; provided that the above copyright notice appear in all copies and that both ; the copyright notice and this permission notice appear in supporting ; documentation, and that any documentation, advertising materials, ; and other materials related to such distribution and use acknowledge ; that the data was released by the University of Southern California, ; Information Sciences Institute, and EP.NET, LLC. ; ; The name of the USC may not be used to endorse or promote products derived ; from this data without specific prior written permission. ; ; THE UNIVERSITY OF SOUTHERN CALIFORNIA AND EP.NET, LLC. MAKE NO ; REPRESENTATIONS ABOUT ; THE SUITABILITY OF THIS DATA FOR ANY PURPOSE. THIS DATA IS ; PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, ; INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF ; MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND ; NON-INFRINGEMENT. ; ; IN NO EVENT SHALL USC, OR ANY OTHER CONTRIBUTOR BE LIABLE FOR ANY ; SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, WHETHER IN CONTRACT, ; TORT, OR OTHER FORM OF ACTION, ARISING OUT OF OR IN CONNECTION WITH, ; THE USE OR PERFORMANCE OF THIS DATA. ; ; This file is made available by Bill Manning ; --------------------------------------------------- From bmanning@ISI.EDU Mon Nov 4 19:21:23 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 4 Nov 2002 11:21:23 -0800 (PST) Subject: [6bone] Re: recursive DNS servers? In-Reply-To: <00cc01c27f27$74458380$3300000a@consulintel.es> from Alvaro Vives at "Oct 29, 2 09:44:53 am" Message-ID: <200211041921.gA4JLNw28222@boreas.isi.edu> [Charset Windows-1252 unsupported, skipping...] the testbed and release were announced on the 6bone list this morning. -- --bill From pim@ipng.nl Tue Nov 5 07:08:07 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 5 Nov 2002 08:08:07 +0100 Subject: [6bone] [spectra@export2000.ro: Romanian Wireless Engineering] Message-ID: <20021105070807.GA17275@bfib.colo.bit.nl> Hi people, If any of you have received the message below, note that your E-mail address was most probably harvested from the 6BONE database. I have been spammed no less than 7 times in the past 24 hours, so this run must have been huge. Can somebody (David?) try to figure out which whois client (or FTP?) was responsible for this and perhaps take measures to ensure that it does not happen again in the future ? (eg IP filtering for the client(s)). Groet, Pim ----- Forwarded message from spectra@export2000.ro ----- Delivered-To: pim+6bone@bfib.ipng.nl Date: Tue, 5 Nov 2002 09:46:03 +0200 From: spectra@export2000.ro To: pim+6bone@ipng.nl Subject: Romanian Wireless Engineering To: pim+6bone@ipng.nl Attn: Marketing Department From: Spectra Telecom Romania Ref.: Romanian Wireless Engineering ------------------------------------------------------------------------ Our anti-spamming company policy (removal instructions): To remove your E-mail address from the present contact list JUST DO NOT REPLY to this message and WE WILL NEVER BOTHER YOU again. If you receive this message by mistake and/or you are not interested in the following brief presentation, please accept our apologies. This is a world-wide promotion campaign. The selected E-mail addresses are extracted only FROM THE COMMERCIAL WEBSITES of the targeted markets. ------------------------------------------------------------------------ -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From bmanning@ISI.EDU Tue Nov 5 19:06:24 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 5 Nov 2002 11:06:24 -0800 (PST) Subject: [6bone] Re: recursive DNS servers? In-Reply-To: <20021027130626.GM15108@pasky.ji.cz> from Petr Baudis at "Oct 27, 2 02:06:26 pm" Message-ID: <200211051906.gA5J6O524663@boreas.isi.edu> % Dear diary, on Tue, Oct 22, 2002 at 05:17:34PM CEST, I got a letter, % where Bill Manning told me, that... % > a question came up recently that I could not answer. % > % > how many recursive IPv6 transport aware DNS % > servers are there? % % That brings another question on my mind.. % % When is at least one of the DNS root servers going to have some v6 connectivity % and an AAAA record? And, on whose this decision depends? Verisign? ICANN? ..? % % (oh, and what's up with 3ffe::/16 ip6.arpafication? ;) % % Kind regards, % % Petr "Pasky" Baudis the production root servers are slowly working up to that state. in the mean time, the post yesterday to the 6bone list has a pointer to the hoop that you can jump through to use v6 enabled root servers and v6 enabled tld servers. the testbed is becoming fully v6 aware. wrt int/arpa, thats moving through the RIR policy process. -- --bill From hans.goes@wcom.com Wed Nov 6 23:08:27 2002 From: hans.goes@wcom.com (Hans Goes) Date: Wed, 6 Nov 2002 23:08:27 +0000 (GMT) Subject: [6bone] power problems amsterdam Message-ID: Hi, Due to power problems in Amsterdam our 6bone router (6b1.ams7.alter.net) went down. 80% of the NUON power network in Amsterdam and surroundings went down. We are currently building a native backbone between amsterdam, london and frankfurt. We are also moving to AS12702 for our ipv6-network in EMEA. Soon we hope to offer you a 2nd tunnel to a box in a different country. Good night, Hans Goes WorldCom EMEA Network Operations Joan Muyskenweg 24 1096 CJ Amsterdam Tel: +31 20 7112428 (Fax: 2455) V-Net: 711 2428 http://www.wcom.com/nl/ From nicolas.deffayet@ndsoftware.net Thu Nov 7 00:42:15 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 07 Nov 2002 01:42:15 +0100 Subject: [6bone] power problems amsterdam In-Reply-To: References: Message-ID: <1036629735.26605.859.camel@wks1.fr.corp.ndsoftware.com> On Thu, 2002-11-07 at 00:08, Hans Goes wrote: Hi, > We are currently building a native backbone between amsterdam, london and > frankfurt. We are also moving to AS12702 for our ipv6-network in EMEA. Do you plan to add Paris in your native backbone ? We are very interested, if UUnet can do native IPv6 peering in Paris. Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From netza@telecom.noc.udg.mx Thu Nov 7 00:51:21 2002 From: netza@telecom.noc.udg.mx (Netzahualcoyotl Ornelas Garcia VOL) Date: Wed, 6 Nov 2002 18:51:21 -0600 (CST) Subject: [6bone] Testing. Message-ID: ** Texto sin acentos. Atte.... ************************************************************************** Netzahualcoyotl Ornelas Garcia. .---. .----------- Coordinacion de Telecomunicaciones y Redes / \ __ / ------ Network Operation Center (NOC). / / \(..)/ ----- University of Guadalajara ////// ' \/ ` --- e-mail: netza@noc.udg.mx ////// // : : --- netza_10@hotmail.com ////// / /` '-- Work Phone: 011(52)3331342220 // //// / //..\ Address: Av. Juarez #976 Planta Baja =============UU====UU==== Col. Centro C.P. 44100 ///////// '//||\` Guadalajara Jal. Mexico. /////// "Ipv6 Staff Working Group" ///// *************************************************************************** From dios-vol@telecom.noc.udg.mx Thu Nov 7 01:07:10 2002 From: dios-vol@telecom.noc.udg.mx (Harold de Dios Tovar) Date: Wed, 6 Nov 2002 19:07:10 -0600 (CST) Subject: [6bone] Testing. In-Reply-To: Message-ID: ok, mensaje recibido.. ** Texto sin acentos --------------------------------- N.O.C & IPv6 staff working Group ------------------------------------ Harold de Dios, harold@noc.udg.mx UdeG, Network Operation Center Work: 011(52)3331342232 ext.2220 --------------------------------- On Wed, 6 Nov 2002, Netzahualcoyotl Ornelas Garcia VOL wrote: > > > ** Texto sin acentos. > Atte.... > ************************************************************************** > Netzahualcoyotl Ornelas Garcia. .---. .----------- > Coordinacion de Telecomunicaciones y Redes / \ __ / ------ > Network Operation Center (NOC). / / \(..)/ ----- > University of Guadalajara ////// ' \/ ` --- > e-mail: netza@noc.udg.mx ////// // : : --- > netza_10@hotmail.com ////// / /` '-- > Work Phone: 011(52)3331342220 // //// / //..\ > Address: Av. Juarez #976 Planta Baja =============UU====UU==== > Col. Centro C.P. 44100 ///////// '//||\` > Guadalajara Jal. Mexico. /////// > "Ipv6 Staff Working Group" ///// > *************************************************************************** > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From hans.goes@wcom.com Thu Nov 7 12:05:53 2002 From: hans.goes@wcom.com (Hans Goes) Date: Thu, 7 Nov 2002 12:05:53 +0000 (GMT) Subject: [6bone] power problems amsterdam In-Reply-To: <1036629735.26605.859.camel@wks1.fr.corp.ndsoftware.com> Message-ID: Hi Nicolas, > > We are currently building a native backbone between amsterdam, london and > > frankfurt. We are also moving to AS12702 for our ipv6-network in EMEA. > Do you plan to add Paris in your native backbone ? > We are very interested, if UUnet can do native IPv6 peering in Paris. We have a ipv6 router running in Nanterre. I'm not sure about peering on the exchange overthere. In Frankfurt we will have a link to the exchange. UUNET is seeing ipv6 as a test-network, so it's just some enthousiasm of some engineers in NL, UK, FR, DE an ZA. Hans Goes WorldCom EMEA Network Operations Joan Muyskenweg 24 1096 CJ Amsterdam Tel: +31 20 7112428 (Fax: 2455) V-Net: 711 2428 http://www.wcom.com/nl/ From nicolas.deffayet@ndsoftware.net Thu Nov 7 12:36:02 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 07 Nov 2002 13:36:02 +0100 Subject: [6bone] power problems amsterdam In-Reply-To: References: Message-ID: <1036672562.26607.1606.camel@wks1.fr.corp.ndsoftware.com> On Thu, 2002-11-07 at 13:05, Hans Goes wrote: Hi Hans, > > > We are currently building a native backbone between amsterdam, london and > > > frankfurt. We are also moving to AS12702 for our ipv6-network in EMEA. > > Do you plan to add Paris in your native backbone ? > > We are very interested, if UUnet can do native IPv6 peering in Paris. > > We have a ipv6 router running in Nanterre. I'm not sure about peering on > the exchange overthere. In Frankfurt we will have a link to the exchange. We don't have a POP in Nanterre. We have a POP in TeleCity Paris where you have a POP too. > UUNET is seeing ipv6 as a test-network, so it's just some enthousiasm of > some engineers in NL, UK, FR, DE an ZA. UUnet don't plan to provide IPv6 production service ? Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From hans.goes@wcom.com Thu Nov 7 13:09:00 2002 From: hans.goes@wcom.com (Hans Goes) Date: Thu, 7 Nov 2002 13:09:00 +0000 (GMT) Subject: [6bone] power problems amsterdam In-Reply-To: <1036672562.26607.1606.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On Thu, 7 Nov 2002, Nicolas DEFFAYET wrote: > > We have a ipv6 router running in Nanterre. I'm not sure about peering on > > the exchange overthere. In Frankfurt we will have a link to the exchange. > We don't have a POP in Nanterre. We have a POP in TeleCity Paris where > you have a POP too. I know... I will discuss this with my french collegue who is on holiday right now. > > UUNET is seeing ipv6 as a test-network, so it's just some enthousiasm of > > some engineers in NL, UK, FR, DE an ZA. > UUnet don't plan to provide IPv6 production service ? Not yet :) But you're always free to pay for it of course :) Hans Goes WorldCom EMEA Network Operations Joan Muyskenweg 24 1096 CJ Amsterdam Tel: +31 20 7112428 (Fax: 2455) V-Net: 711 2428 http://www.wcom.com/nl/ From trent@irc-desk.net Thu Nov 7 15:01:52 2002 From: trent@irc-desk.net (Trent Lloyd) Date: Thu, 07 Nov 2002 23:01:52 +0800 Subject: [6bone] BGP Howto Message-ID: <5.1.0.14.0.20021107230133.018273f8@mail.iprimus.com.au> I can't for the life of me find any descent 'howto' documentation on setting up BGP related to Ipv6, how to get it going, feeding to clients etc. Can someone point me to some? Trent Lloyd [Lathat] Jan 22-25 2003 Linux.Conf.AU http://linux.conf.au/ The Australian Linux Technical Conference! From bortzmeyer@gitoyen.net Thu Nov 7 21:02:22 2002 From: bortzmeyer@gitoyen.net (Stephane Bortzmeyer) Date: Thu, 07 Nov 2002 22:02:22 +0100 Subject: [6bone] BGP Howto In-Reply-To: <5.1.0.14.0.20021107230133.018273f8@mail.iprimus.com.au> (Trent Lloyd 's message of Thu, 07 Nov 2002 23:01:52 +0800) Message-ID: <200211072102.gA7L2MVS007370@ludwigV.sources.org> On Thursday 7 November 2002, at 23 h 1, Trent Lloyd wrote: > I can't for the life of me find any descent 'howto' documentation on > setting up BGP related to Ipv6, The differences with BGP for IPv4 are small. The concepts are the same. The commands depend on your specific router. Are you already knowledgeable in BGP with IPv4? If yes, just read the documentation of your router to find the new commands/options. If no, Sam Halabi's book "Internet Routing Architectures" (Cisco press) is the best one to learn BGP, IMHO. From ji@research.att.com Thu Nov 7 22:18:36 2002 From: ji@research.att.com (John Ioannidis) Date: Thu, 7 Nov 2002 17:18:36 -0500 Subject: [6bone] BGP Howto In-Reply-To: <200211072102.gA7L2MVS007370@ludwigV.sources.org>; from Stephane Bortzmeyer on Thu, Nov 07, 2002 at 10:02:22PM +0100 References: <5.1.0.14.0.20021107230133.018273f8@mail.iprimus.com.au> <200211072102.gA7L2MVS007370@ludwigV.sources.org> Message-ID: <20021107171836.C19955@bual.research.att.com> On Thu, Nov 07, 2002 at 10:02:22PM +0100, Stephane Bortzmeyer wrote: ... > Are you already knowledgeable in BGP with IPv4? If yes, just read the > documentation of your router to find the new commands/options. If no, Sam > Halabi's book "Internet Routing Architectures" (Cisco press) is the best one > to learn BGP, IMHO. I've found Stewart's book a much better introduction to BGP: John W. Stewart: BGP4 Interdomain Routing in the Internet. ISBN 0-201-37951-1 If you've never seen BGP before, you'll get lost with Halabi. Read it after you've read Stewart. You may also want to check out http://www.cs.columbia.edu/~ji/F02/. That's the home page of the graduate-level routing course I'm teaching at Columbia this semester. Lectures 12-17 are on BGP. /ji -- /\ ASCII ribbon | John "JI" Ioannidis * Secure Systems Research Department \/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 * USA /\ against | "Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals" (Fritz the Cat) From old_mc_donald@hotmail.com Fri Nov 8 08:32:02 2002 From: old_mc_donald@hotmail.com (Gav) Date: Fri, 8 Nov 2002 16:32:02 +0800 Subject: [6bone] IPv6 connection + website. Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C28744.5DCD0B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All,=20 Is somebody in the Perth,Australia area willing to connect me as an end = user? The nearest I could find was in Tasmania (who Im not discounting) but = thought the nearer the better. Secondly, what sort of connection/extra equipment would I need to be = able to run (experiment only) an IPv6 website. I have WinXP Pro with Apache 2. I have successfully set up 2 websites on my Apache Server however these = need 3rd party software to forward the dynamic ISP assigned IP4 address. Im guessing that I would get a permanant IPv6 address from someone so = this would=20 make my life easier in setting up the IPv6 site. Thinking about it, would having a static IPv6 address help me with my v4 = sites also? Thanks in advance. Gavin... --- Checked for Viruses (Viri) , Gav... Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 ------=_NextPart_000_000C_01C28744.5DCD0B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Is somebody in the Perth,Australia area = willing to=20 connect me as an end user?
 
The nearest I could find was in = Tasmania (who Im=20 not discounting) but thought
the nearer the better.
 
Secondly, what sort of connection/extra = equipment=20 would I need to be able to
run (experiment only) an IPv6 = website.
 
I have WinXP Pro with Apache = 2.
I have successfully set up 2 websites = on=20 my Apache Server however these need
3rd party software to forward the = dynamic ISP=20 assigned IP4 address.
 
Im guessing that I would get a = permanant IPv6=20 address from someone so this would
make my life easier in setting up the = IPv6=20 site.
 
Thinking about it, would having a = static IPv6=20 address help me with my v4 sites also?
 
Thanks in advance.
 
Gavin...
 

---
Checked for Viruses (Viri) , = Gav...
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.410 /=20 Virus Database: 231 - Release Date: = 31/10/2002
------=_NextPart_000_000C_01C28744.5DCD0B80-- From fink@es.net Fri Nov 8 23:46:18 2002 From: fink@es.net (Bob Fink) Date: Fri, 08 Nov 2002 15:46:18 -0800 Subject: [6bone] NDSOFTWARE pTLA review Message-ID: <5.1.0.14.0.20021108152241.031ccea8@imap2.es.net> 6bone Folk, At the completion of the NDSOFTWARE pTLA request open review period, I formed a pTLA review panel to further look at the issues raised by this request as well as to make a final decision on allocation, and whether the current pTLA rules as outlined in RFC2772 need updating. The folks that agreed to participate in the panel were: Bob Fink, Chair (co-author of RFC2772) David Kessens (6bone registry developer/manager, and of NOKIA) Rob Rockell (co-author of RFC2772, and of SPRINT) Jun-ichiro itojun Hagino (IIJ and WIDE project) Gert Doering (SpaceNet) After careful review, and further questions asked of, and answered by, Nicolas Deffayet, the panel unanimously agrees that NDSOFTWARE should be granted their pTLA allocation. This is not to say that we are completely comfortable with the rules we are currently operating under. In fact, we also unanimously agreed that RFC2772 is in need of considerable community review and updating to assist in deciding future pTLA requests, as well as giving guidance to the operation of the 6bone. To this end, we would like to establish a process to do the RFC2772 rework that guarantees all voices are heard and input taken. We will shortly publish to this list our recommendation on how to do this. Returning again to the pTLA request of NDSOFTWARE, we respectfully ask that contentious and divisive discussion of the allocation itself cease, and be replaced by a good and vigorous discussion of the issues the 6bone needs to address going forward. Thanks for your patience, and thanks to my fellow panel members for helping. Bob From jeroen@unfix.org Sat Nov 9 01:37:38 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Sat, 9 Nov 2002 02:37:38 +0100 Subject: [6bone] IPv6 connection + website. In-Reply-To: Message-ID: <004e01c28790$9719dc50$210d640a@unfix.org> Gav wrote: > Hi All, > > Is somebody in the Perth,Australia area willing to connect me > as an end user? > > The nearest I could find was in Tasmania (who Im not > discounting) but thought > the nearer the better. You could try Trumpet (http://www.trumpet.com/ipv6.htm) http://www.cs-ipv6.lancs.ac.uk/ftp-archive/6Bone/Maps/world.gif Hmm only two spots there :( http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/bycountry.html#AU A couple more there, if I where you I would give them a try. Then again geographically close doesn't always mean network-close ;) Greets from literally the other side of the world, Jeroen (The Netherlands :) From old_mc_donald@hotmail.com Sat Nov 9 01:41:04 2002 From: old_mc_donald@hotmail.com (Gav) Date: Sat, 9 Nov 2002 09:41:04 +0800 Subject: [6bone] IPv6 connection + website. References: <200211081949.gA8JnhJt030229@marajade.sandelman.ottawa.on.ca> Message-ID: ----- Original Message ----- From: "Michael Richardson" To: "Gav" Sent: Saturday, November 09, 2002 3:49 AM Subject: Re: [6bone] IPv6 connection + website. > > Install NetBSD on a PC, and use that. > Thanks for your reply, can you explain what part of my posting you were answering with your reply? Will this solve my website query? I will take a look at NetBSD for my purposes, but still think Windoze will be the platform of choice of most end users and so needs to be kept abreast of. Thanks, Gavin ___________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone --- Checked for Viruses (Viri) , Gav... Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 From old_mc_donald@hotmail.com Sat Nov 9 02:07:34 2002 From: old_mc_donald@hotmail.com (Gav) Date: Sat, 9 Nov 2002 10:07:34 +0800 Subject: [6bone] IPv6 connection + website. References: <004e01c28790$9719dc50$210d640a@unfix.org> Message-ID: ----- Original Message ----- From: "Jeroen Massar" To: "'Gav'" ; <6bone@mailman.isi.edu> Sent: Saturday, November 09, 2002 9:37 AM Subject: RE: [6bone] IPv6 connection + website. > You could try Trumpet (http://www.trumpet.com/ipv6.htm) Yes, these were the ones I was thinking of (Tasmania) , they are also Internet2. > > http://www.cs-ipv6.lancs.ac.uk/ftp-archive/6Bone/Maps/world.gif > > Hmm only two spots there :( > > http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/bycountry.html#AU > > A couple more there, if I where you I would give them a try. I have looked at this list and checked them out, discounting all but 3. I have contacted but recieved no reply from Digital and Connect. Looking on Belkins site they/he seems to be having a revamp and might not be able to offer the services I need at this time. I will give Trumpet another try. > > Then again geographically close doesn't always mean network-close ;) No, Australia seems to be a bit 6bone sparse at the moment. For me though, any connection here geographically must be better network wise too, as opposed to overseas. Population wise, Australia must concentrate on the Cities and surrounding areas to locate the backbone, Sydney,Brisbane,Adelaide,Darwin,Perth,Hobart,Cairns. Internet2 has AARNET influence in most of these places. > > Greets from literally the other side of the world, > Jeroen > > (The Netherlands :) Thanks for your reply. > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > --- Checked for Viruses (Viri) , Gav... Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 From old_mc_donald@hotmail.com Sat Nov 9 02:21:45 2002 From: old_mc_donald@hotmail.com (Gav) Date: Sat, 9 Nov 2002 10:21:45 +0800 Subject: [6bone] www.6bone.not Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C287D9.CE377870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All,=20 Not an emergency I know but if we can't get the front end to the public = right! :- I have noticed that most 6bone and related sites quote the main = information site as www.6bone.net , this does not and has not worked for some time. Should = this not be changed to read http://6bone.net as this one works (or get the www.6bone.net working). Also www.6bone.com redirects to Plexos.com - a web design Company, = which=20 contains little more than 1 page of links to other 6bone sites, whats = going on there then? Regards, Gavin... --- Checked for Viruses (Viri) , Gav... Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 ------=_NextPart_000_0019_01C287D9.CE377870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Not an emergency I know but if we can't = get the=20 front end to the public right! :-
 
I have noticed that most 6bone and = related sites=20 quote the main information site as
www.6bone.net , this does not and has = not worked=20 for some time. Should this not be changed to read
http://6bone.net as this one works (or get = the www.6bone.net working).
     Also www.6bone.com redirects to Plexos.com = - a web=20 design Company, which
contains little more than 1 page of links to = other=20 6bone sites, whats going on there then?
 
Regards,
 
Gavin...
 

---
Checked for Viruses (Viri) , = Gav...
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.410 /=20 Virus Database: 231 - Release Date: = 31/10/2002
------=_NextPart_000_0019_01C287D9.CE377870-- From ck@arch.bellsouth.net Sat Nov 9 03:07:55 2002 From: ck@arch.bellsouth.net (Christian Kuhtz) Date: Fri, 8 Nov 2002 22:07:55 -0500 Subject: [6bone] www.6bone.not In-Reply-To: ; from Gav on Sat, Nov 09, 2002 at 10:21:45AM +0800 References: Message-ID: <20021108220755.D9045@ns1.arch.bellsouth.net> On Sat, Nov 09, 2002 at 10:21:45AM +0800, Gav wrote: [..] > I have noticed that most 6bone and related sites quote the main information site as > www.6bone.net , this does not and has not worked for some time. Should this not be changed to read > http://6bone.net as this one works (or get the www.6bone.net working). http://www.6bone.net or http://6bone.net works just fine for me. ipv4 or ipv6. thanks, christian From andrew@asol.com.ph Sat Nov 9 03:25:14 2002 From: andrew@asol.com.ph (Madrigallos, Andrew G.) Date: Sat, 9 Nov 2002 11:25:14 +0800 Subject: [6bone] www.6bone.not References: Message-ID: <001201c2879f$a1d2ece0$e1feafca@andrew> This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C287E2.ACB9EDA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To Gav, Maybe there is a problem on your DNS, www.6bone.net is working fine. Andrew ----- Original Message -----=20 From: Gav=20 To: 6bone@mailman.isi.edu=20 Sent: Saturday, November 09, 2002 10:21 Andrew Subject: [6bone] www.6bone.not Hi All,=20 Not an emergency I know but if we can't get the front end to the = public right! :- I have noticed that most 6bone and related sites quote the main = information site as www.6bone.net , this does not and has not worked for some time. Should = this not be changed to read http://6bone.net as this one works (or get the www.6bone.net working). Also www.6bone.com redirects to Plexos.com - a web design = Company, which=20 contains little more than 1 page of links to other 6bone sites, whats = going on there then? Regards, Gavin... --- Checked for Viruses (Viri) , Gav... Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 ------=_NextPart_000_000F_01C287E2.ACB9EDA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
To Gav,
 
Maybe there is a problem on your DNS, www.6bone.net is working = fine.
 
Andrew
----- Original Message -----
From:=20 Gav
Sent: Saturday, November 09, = 2002 10:21=20 Andrew
Subject: [6bone] www.6bone.not

Hi All,
 
Not an emergency I know but if we = can't get the=20 front end to the public right! :-
 
I have noticed that most 6bone and = related sites=20 quote the main information site as
www.6bone.net , this does not and = has not=20 worked for some time. Should this not be changed to read
http://6bone.net as this one works (or = get the www.6bone.net working).
     Also www.6bone.com redirects to = Plexos.com - a web=20 design Company, which
contains little more than 1 page of links to = other=20 6bone sites, whats going on there then?
 
Regards,
 
Gavin...
 

---
Checked for Viruses (Viri) = ,=20 Gav...
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.410=20 / Virus Database: 231 - Release Date:=20 31/10/2002
------=_NextPart_000_000F_01C287E2.ACB9EDA0-- From john@sixgirls.org Sat Nov 9 03:29:24 2002 From: john@sixgirls.org (John Klos) Date: Fri, 8 Nov 2002 22:29:24 -0500 (EST) Subject: [6bone] IPv6 connection + website. In-Reply-To: Message-ID: Hello, > > Install NetBSD on a PC, and use that. > > Thanks for your reply, can you explain what part of my posting you were > answering with your reply? > Will this solve my website query? I think this is a good suggestion, as IPv6 on Windows is something of a hack. Unless your intention is to learn the idiosyncracies of IPv6 on Windows, using an operating system that does IPv6 very well is a very good idea. It all depends on what you want to learn - the process (of setting up IPv6) or the practise (of running IPv6). Windows involves much more process, and NetBSD much more practise. > I will take a look at NetBSD for my purposes, but still think Windoze will > be the platform of choice of most end users and so needs to be kept abreast > of. Is your goal to learn how to deploy IPv6, or how to use IPv6 in a Windows environment? If it's the latter, then this list isn't for you; our goal is IPv6 deployment for the world and the lan alike, and, like the current IPv4 Internet, for everyone regardless of OS. To put it simply, one does not deploy for a specific OS when one deploys for the Internet (well, people do, but it's not correct). The same is true of IPv6. Thanks, John Klos Sixgirls Computing Labs From john@sixgirls.org Sat Nov 9 04:00:39 2002 From: john@sixgirls.org (John Klos) Date: Fri, 8 Nov 2002 23:00:39 -0500 (EST) Subject: [6bone] www.6bone.not In-Reply-To: Message-ID: Hi, > I have noticed that most 6bone and related sites quote the main > information site as www.6bone.net , this does not and has not worked for > some time. Should this not be changed to read http://6bone.net as this > one works (or get the www.6bone.net working). Is there any chance that there is something wrong with your DNS server or setup? Everything seems fine here: dig 6bone.net: 6bone.net. 59m41s IN A 131.243.129.43 dig www.6bone.net: www.6bone.net. 1H IN CNAME 6bone.net. 6bone.net. 1H IN A 131.243.129.43 andromeda: {4} ping6 6bone.net PING6(56=40+8+8 bytes) 3ffe:b80:2:fb9d::2 --> 3ffe:b00:c18:1::10 16 bytes from 3ffe:b00:c18:1::10, icmp_seq=0 hlim=62 time=30.098 ms andromeda: {5} ping6 www.6bone.net PING6(56=40+8+8 bytes) 3ffe:b80:2:fb9d::2 --> 3ffe:b00:c18:1::10 16 bytes from 3ffe:b00:c18:1::10, icmp_seq=0 hlim=63 time=27.741 ms > Also www.6bone.com redirects to Plexos.com - a web design Company, > which contains little more than 1 page of links to other 6bone sites, > whats going on there then? It appears that 6bone.com is owned by a domain squatter.... Best, John Klos Sixgirls Computing Labs From old_mc_donald@hotmail.com Sat Nov 9 04:04:04 2002 From: old_mc_donald@hotmail.com (Gav) Date: Sat, 9 Nov 2002 12:04:04 +0800 Subject: [6bone] www.6bone.not References: <001201c2879f$a1d2ece0$e1feafca@andrew> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C287E8.198479F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Madrigallos, Andrew G.=20 To: 6bone@mailman.isi.edu=20 Sent: Saturday, November 09, 2002 11:25 AM Subject: Re: [6bone] www.6bone.not To Gav, Maybe there is a problem on your DNS, www.6bone.net is working fine. Andrew To Andrew and all,=20 It must be me then, apologies. Typing in www.6bone.net gets a 'Can not find ..' error message. Typing in http://www.6bone.net gets a 'Page can not be displayed..' = error message. Typing in http://6bone.net works just fine. Gav... --- Checked for Viruses (Viri) , Gav... Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 ------=_NextPart_000_0013_01C287E8.198479F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From:=20 Madrigallos,=20 Andrew G.
Sent: Saturday, November 09, = 2002 11:25=20 AM
Subject: Re: [6bone] www.6bone.not

To Gav,
 
Maybe there is a problem on your DNS, www.6bone.net is working = fine.
 
Andrew
 
To Andrew and all,
 
It must be me then, = apologies.
 
Typing in www.6bone.net gets a 'Can not find = ..' error=20 message.
Typing in http://www.6bone.net gets a 'Page = can not be=20 displayed..' error message.
Typing in http://6bone.net works just = fine.
 
Gav...
 

---
Checked for Viruses (Viri) = ,=20 Gav...
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.410=20 / Virus Database: 231 - Release Date:=20 31/10/2002
------=_NextPart_000_0013_01C287E8.198479F0-- From mrp@mrp.net Sat Nov 9 04:09:03 2002 From: mrp@mrp.net (Mark Prior) Date: Sat, 9 Nov 2002 14:39:03 +1030 Subject: [6bone] IPv6 connection + website. In-Reply-To: References: <004e01c28790$9719dc50$210d640a@unfix.org> Message-ID: At 10:07 AM +0800 9/11/02, Gav wrote: >I have looked at this list and checked them out, discounting all but 3. >I have contacted but recieved no reply from Digital and Connect. >Looking on Belkins site they/he seems to be having a revamp and might >not be able to offer the services I need at this time. > I'm not sure who would be on the Connect mailing list ipv6-contact@connect.com.au but neither Chris Chaundy nor I work there anymore so maybe no one is home on that list. I suspect that Connect would only be interested if you are a customer, and only if you are persistent at nagging them :-) If you are a customer then try sending email to support@connect.com.au. Mark. From stansley@microsoft.com Sat Nov 9 04:11:12 2002 From: stansley@microsoft.com (Stewart Tansley) Date: Fri, 8 Nov 2002 20:11:12 -0800 Subject: [6bone] IPv6 connection + website. Message-ID: <240659DFBDD99C4299EF7483EAD70F24EFBC2C@RED-MSG-01.redmond.corp.microsoft.com> > I think this is a good suggestion, as IPv6 on Windows is > something of a hack. !! -- perhaps you are confusing the preview editions of the IPv6 stack on Windows, such as the well-known Windows 2000 technology preview, which were issued as Microsoft gradually refined its implementation prior to releasing a fully-supported stack. These preview editions were unsupported. Microsoft today offers fully-supported IPv6 stacks in all of: - Windows XP with Service Pack 1 (Professional and Home Editions) - Windows XP Embedded with Service Pack 1 - Windows CE .NET Windows .NET Server 2003 family in beta is also available, as a free download. > Unless your intention is to learn the > idiosyncracies of IPv6 on Windows, using an operating system > that does IPv6 very well is a very good idea. It all depends > on what you want to learn - the process (of setting up IPv6) > or the practise (of running IPv6). Windows involves much more > process, and NetBSD much more practise. I don't understand where this view is coming from. We welcome feedback on our supported IPv6 implementations at ipv6-fb@microsoft.com. Setting up IPv6 on a supported stack Windows OS is as simple as executing one command or a couple of clicks in a dialog box. > Is your goal to learn how to deploy IPv6, or how to use IPv6 > in a Windows environment? If it's the latter, then this list > isn't for you; our goal is IPv6 deployment for the world and > the lan alike, and, like the current IPv4 Internet, for > everyone regardless of OS. Microsoft enjoys this list too. We hadn't noticed any OS bias. > To put it simply, one does not deploy for a specific OS when > one deploys for the Internet (well, people do, but it's not > correct). The same is true of IPv6. There are all sorts of reasons why people deploy all sorts of platforms. Which platforms are used should be determined by analyzing requirements and matching capabilities. Stewart Tansley Program Manager http://www.microsoft.com/ipv6/ From mrp@mrp.net Sat Nov 9 04:12:41 2002 From: mrp@mrp.net (Mark Prior) Date: Sat, 9 Nov 2002 14:42:41 +1030 Subject: [6bone] IPv6 connection + website. In-Reply-To: <004e01c28790$9719dc50$210d640a@unfix.org> References: <004e01c28790$9719dc50$210d640a@unfix.org> Message-ID: At 2:37 AM +0100 9/11/02, Jeroen Massar wrote: >You could try Trumpet (http://www.trumpet.com/ipv6.htm) > >http://www.cs-ipv6.lancs.ac.uk/ftp-archive/6Bone/Maps/world.gif > >Hmm only two spots there :( > It would be interesting to know how that map was created since I believe that Trumpet has been doing IPv6 the longest and it's not one of the two spots (and Tasmania is AWOL from the map :-) I also suspect that Japan should be coloured red :-) Mark. From john@sixgirls.org Sat Nov 9 04:24:23 2002 From: john@sixgirls.org (John Klos) Date: Fri, 8 Nov 2002 23:24:23 -0500 (EST) Subject: [6bone] IPv6 connection + website. In-Reply-To: <240659DFBDD99C4299EF7483EAD70F24EFBC2C@RED-MSG-01.redmond.corp.microsoft.com> Message-ID: > > I think this is a good suggestion, as IPv6 on Windows is > > something of a hack. > > !! -- perhaps you are confusing the preview editions of the IPv6 stack > on Windows, such as the well-known Windows 2000 technology preview, > which were issued as Microsoft gradually refined its implementation > prior to releasing a fully-supported stack. These preview editions were > unsupported. Yes, my experience is probably a bit dated. > Microsoft enjoys this list too. We hadn't noticed any OS bias. > > > To put it simply, one does not deploy for a specific OS when > > one deploys for the Internet (well, people do, but it's not > > correct). The same is true of IPv6. > > There are all sorts of reasons why people deploy all sorts of platforms. > Which platforms are used should be determined by analyzing requirements > and matching capabilities. I'm sorry - perhaps I could've made my point a little more succinct by saying that an OS-specific approach to learning new technology does not lend itself to broad deployment. Gav incorrectly implied a dependency between a server's OS type and the client's OS type (in the context of IPv6 and web serving), and such incorrect thinking often leads to improper deployment. John Klos Sixgirls Computing Labs From basit@basit.cc Sat Nov 9 11:39:59 2002 From: basit@basit.cc (Abdul Basit) Date: Sat, 9 Nov 2002 05:39:59 -0600 (CST) Subject: [6bone] best OS for ipv6 router. Message-ID: Hello, What's the best OS to be run as ipv6 router ? linux or freebsd (usagi or kame), from the facts we observe kame is mature(more stable) than USAGI? By the means of libc, does glibc supports most of things described in sockets programming rfc's ? or freebsd libc ? for example , i'm not still able to get exim to listen on USAGI ipv6 sockets or bind9. exim4 works on plain linux ipv6 support but not on usagi (as far as my experience). In short, for an instance if you want to run a super duper IPv6 router what OS you should use(linux,freebsd) ? I'm not talking about cisco routers. take care - basit From tjc@ecs.soton.ac.uk Sat Nov 9 09:46:09 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Sat, 9 Nov 2002 09:46:09 +0000 Subject: [6bone] www.6bone.not In-Reply-To: <001201c2879f$a1d2ece0$e1feafca@andrew> References: <001201c2879f$a1d2ece0$e1feafca@andrew> Message-ID: <20021109094609.GB736@login.ecs.soton.ac.uk> Or maybe like me he's on BT Openworld's UK DSL service, which has been screwed up for 10 days now, witrh customers unable to reach a lare chunk of web sites. I despair for such an ISP deploying IPv6 when they can't even support IPv4. Tim On Sat, Nov 09, 2002 at 11:25:14AM +0800, Madrigallos, Andrew G. wrote: > To Gav, > > Maybe there is a problem on your DNS, www.6bone.net is working fine. > > Andrew > ----- Original Message ----- > From: Gav > To: 6bone@mailman.isi.edu > Sent: Saturday, November 09, 2002 10:21 Andrew > Subject: [6bone] www.6bone.not > > > Hi All, > > Not an emergency I know but if we can't get the front end to the public right! :- > > I have noticed that most 6bone and related sites quote the main information site as > www.6bone.net , this does not and has not worked for some time. Should this not be changed to read > http://6bone.net as this one works (or get the www.6bone.net working). > Also www.6bone.com redirects to Plexos.com - a web design Company, which > contains little more than 1 page of links to other 6bone sites, whats going on there then? > > Regards, > > Gavin... > > > --- > Checked for Viruses (Viri) , Gav... > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 From jeroen@unfix.org Sat Nov 9 10:09:03 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Sat, 9 Nov 2002 11:09:03 +0100 Subject: [6bone] IPv6 connection + website. In-Reply-To: Message-ID: <001801c287d8$0844d690$210d640a@unfix.org> John Klos wrote: > Hello, > > > > Install NetBSD on a PC, and use that. Install the OS you need and install that on whatever hardware you got and/or want. > > > > Thanks for your reply, can you explain what part of my > posting you were > > answering with your reply? > > Will this solve my website query? > > I think this is a good suggestion, as IPv6 on Windows is > something of a hack. Unless your intention is to learn the idiosyncracies of IPv6 on > Windows, using an operating system that does IPv6 very well > is a very good idea. It all depends on what you want to learn - the process > (of setting up IPv6) or the practise (of running IPv6). Windows involves much more > process, and NetBSD much more practise. Ehm what kind of weird statement is that? What is so peeping difficult at reading documents to configure stuff? One doesn't even have to for both OS's (ipv6 install and rtsold :) Calling the Windows IPv6 stack is really odd as it's a fine nice working seperate IPv6 stack independent of the IPv4 one. It all works very well. Could you also explain the "iodiosyncracies" whatever that may be?? And what is the hacking involved in there? Every stack has their oddities and without them it wouldn't be fun now would it ? > Is your goal to learn how to deploy IPv6, or how to use IPv6 in a Windows > environment? If it's the latter, then this list isn't for > you; our goal is IPv6 deployment for the world and the lan alike, and, like the current > IPv4 Internet, for everyone regardless of OS. Indeed _regardless_ of OS, and why the peep can't he use Windows for that? It works perfectly well as one, even though some people prefer this and other people prefer that. Also IMHO I think the 'process' part for learning a complete UNIX system is much higher than learning Windows, which is mostly the reason most people use Windows. Lower learning curve or 'process' as you like to call it. > To put it simply, one does not deploy for a specific OS when > one deploys for the Internet (well, people do, but it's not correct). The > same is true of IPv6. You didn't read/see Lord Of The Rings yet I assume: One protocol to bind them all, multiple program's to use it all, multiple OS'es to run it all" Ah well it at least looks a bit like that one thingy :) Translated into english: Use what you want wherever you want when and whereever you need it. Greets, Jeroen From pim@ipng.nl Sat Nov 9 11:30:16 2002 From: pim@ipng.nl (Pim van Pelt) Date: Sat, 9 Nov 2002 12:30:16 +0100 Subject: [6bone] NDSOFTWARE pTLA review In-Reply-To: <5.1.0.14.0.20021108152241.031ccea8@imap2.es.net> References: <5.1.0.14.0.20021108152241.031ccea8@imap2.es.net> Message-ID: <20021109113016.GA10687@bfib.colo.bit.nl> Dear committee members, | After careful review, and further questions asked of, and answered by, | Nicolas Deffayet, the panel unanimously agrees that NDSOFTWARE should be | granted their pTLA allocation. Such a decision was made only after very careful consideration and I will no longer doubt the validity of DEFFAYETs pTLA that will be granted to him and/or NDSoftware. I trust your good judgment in this case, even though we disagree. Thanks for the time you spent on the matter. I think Bob makes a valid point that we should revise RFC2772 to make the pTLA allocation request less ambiguous in the future. Let's procede with 6BONE and keep this list at the high quality standard that it's always been ! Kind regards, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From Q@ping.be Sat Nov 9 12:54:28 2002 From: Q@ping.be (Kurt Roeckx) Date: Sat, 9 Nov 2002 13:54:28 +0100 Subject: [6bone] www.6bone.not In-Reply-To: ; from old_mc_donald@hotmail.com on Sat, Nov 09, 2002 at 10:21:45AM +0800 References: Message-ID: <20021109135427.A1340@ping.be> On Sat, Nov 09, 2002 at 10:21:45AM +0800, Gav wrote: > I have noticed that most 6bone and related sites quote the main information site as > www.6bone.net , this does not and has not worked for some time. Should this not be changed to read > http://6bone.net as this one works (or get the www.6bone.net working). www.6bone.net. 1H IN CNAME 6bone.net. Looks weird to me that 1 would work and the other not. Kurt From hans.goes@wcom.com Sat Nov 9 13:11:34 2002 From: hans.goes@wcom.com (Hans Goes) Date: Sat, 9 Nov 2002 13:11:34 +0000 (GMT) Subject: [6bone] Cisco bug ? Message-ID: Hi, We're using a Cisco 7507 with a RSP4+ (256meg). 6B1.AMS7#ping 2001:820:0:1:1::2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:820:0:1:1::2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 40/64/100 ms 6B1.AMS7#conf t Enter configuration commands, one per line. End with CNTL/Z. 6B1.AMS7(config)#router bgp 1890 6B1.AMS7(config-router)#neighbor 2001:820:0:1:1::2 remote-as 16186 6B1.AMS7(config-router)#address-family ipv6 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit % Activate the peer-group for the address family first 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit % Activate the peer-group for the address family first 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit % Activate the peer-group for the address family first Any idea ? I've had this problem a couple of times but still the same problem. Sometimes a router reload helps... But that's not the way we want it :) System image file is "slot0:rsp-pv-mz.122-0.5.T.bin" Hans WorldCom EMEA Network Operations Joan Muyskenweg 24 1096 CJ Amsterdam Tel: +31 20 7112428 (Fax: 2455) V-Net: 711 2428 http://www.wcom.com/nl/ From daniel@kewlio.net Sat Nov 9 13:31:51 2002 From: daniel@kewlio.net (Daniel Austin) Date: Sat, 9 Nov 2002 13:31:51 -0000 (GMT) Subject: [6bone] www.6bone.not In-Reply-To: <20021109094609.GB736@login.ecs.soton.ac.uk> References: <001201c2879f$a1d2ece0$e1feafca@andrew> <20021109094609.GB736@login.ecs.soton.ac.uk> Message-ID: <1667.81.6.207.27.1036848711.squirrel@webmail.kewlio.net> Hi Tim, Luckily IPv6 at BT is currently handled by BTexact, not BTopenworld ;-) Their ipv6 team are very helpful and i've had zero problems from them. Sadly, their DSL sucks :) Daniel. > Or maybe like me he's on BT Openworld's UK DSL service, which has been > screwed up for 10 days now, witrh customers unable to reach a lare chunk > of web sites. I despair for such an ISP deploying IPv6 when they can't > even support IPv4. > > Tim > > On Sat, Nov 09, 2002 at 11:25:14AM +0800, Madrigallos, Andrew G. wrote: >> To Gav, >> >> Maybe there is a problem on your DNS, www.6bone.net is working fine. >> >> Andrew >> ----- Original Message ----- >> From: Gav >> To: 6bone@mailman.isi.edu >> Sent: Saturday, November 09, 2002 10:21 Andrew >> Subject: [6bone] www.6bone.not >> >> >> Hi All, >> >> Not an emergency I know but if we can't get the front end to the >> public right! :- >> >> I have noticed that most 6bone and related sites quote the main >> information site as www.6bone.net , this does not and has not worked >> for some time. Should this not be changed to read http://6bone.net >> as this one works (or get the www.6bone.net working). >> Also www.6bone.com redirects to Plexos.com - a web design >> Company, which >> contains little more than 1 page of links to other 6bone sites, >> whats going on there then? >> >> Regards, >> >> Gavin... >> >> >> --- >> Checked for Viruses (Viri) , Gav... >> Checked by AVG anti-virus system (http://www.grisoft.com). >> Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone -- With Thanks, Daniel Austin, Managing Director, Kewlio.net Limited. From czmok@gatel.net Sat Nov 9 13:39:55 2002 From: czmok@gatel.net (Jan Czmok) Date: Sat, 9 Nov 2002 14:39:55 +0100 Subject: [6bone] Cisco bug ? In-Reply-To: References: Message-ID: <20021109133955.GA17098@gollum.gatel.net> Hans Goes (hgoes@eu.uu.net) wrote: > Hi, > > We're using a Cisco 7507 with a RSP4+ (256meg). > > 6B1.AMS7#ping 2001:820:0:1:1::2 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 2001:820:0:1:1::2, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 40/64/100 ms > 6B1.AMS7#conf t > Enter configuration commands, one per line. End with CNTL/Z. > 6B1.AMS7(config)#router bgp 1890 > 6B1.AMS7(config-router)#neighbor 2001:820:0:1:1::2 remote-as 16186 > 6B1.AMS7(config-router)#address-family ipv6 > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > % Activate the peer-group for the address family first > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > % Activate the peer-group for the address family first > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > % Activate the peer-group for the address family first > > Any idea ? I've had this problem a couple of times but still the same > problem. Sometimes a router reload helps... But that's not the way we want > it :) > > System image file is "slot0:rsp-pv-mz.122-0.5.T.bin" > it's quite easy: router bgp 1890ß address-family ipv6 neighbor transit activate then then the above... --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de From gert@space.net Sat Nov 9 13:52:35 2002 From: gert@space.net (Gert Doering) Date: Sat, 9 Nov 2002 14:52:35 +0100 Subject: [6bone] Cisco bug ? In-Reply-To: ; from hgoes@eu.uu.net on Sat, Nov 09, 2002 at 01:11:34PM +0000 References: Message-ID: <20021109145235.D94537@Space.Net> hi, On Sat, Nov 09, 2002 at 01:11:34PM +0000, Hans Goes wrote: > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > % Activate the peer-group for the address family first I think the trick is to have a: address-family ipv6 neigh transit activate in there - if the *peer-group* isn't activated for a specific address family, you can't apply it to the neighbor for that family. [..] > Any idea ? I've had this problem a couple of times but still the same > problem. Sometimes a router reload helps... But that's not the way we want > it :) Of course if the problem appears only intermittant, the chance is very high that you're hitting a bug. > System image file is "slot0:rsp-pv-mz.122-0.5.T.bin" If the router in question is doing v6 only, you might have good results with 12.0(11)T2 (but we have seen a ghost bug recently that might have been caused by that version, so beware). If the router is doing v4 plus v6 and eventually v4 multicast, I can't recommend any image to you. All 12.2T images that I've heard of are broken for that purpose. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48540 (48282) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owens@nysernet.org Sat Nov 9 14:02:11 2002 From: owens@nysernet.org (owens@nysernet.org) Date: Sat, 9 Nov 2002 09:02:11 -0500 (EST) Subject: [6bone] Cisco bug ? In-Reply-To: Message-ID: We routinely have problems with the router not putting the 'neighbor activate' statement in the config, so that after a reload the peers don't come back. It requires a manual activate, after which you can paste in the relevant config lines. I don't recall if there's a bug open on this one or not, though Cisco certainly knows about it. Bill. From owens@nysernet.org Sat Nov 9 14:20:15 2002 From: owens@nysernet.org (owens@nysernet.org) Date: Sat, 9 Nov 2002 09:20:15 -0500 (EST) Subject: [6bone] Cisco bug ? In-Reply-To: <20021109145235.D94537@Space.Net> Message-ID: On Sat, 9 Nov 2002, Gert Doering wrote: > If the router is doing v4 plus v6 and eventually v4 multicast, I can't > recommend any image to you. All 12.2T images that I've heard of are > broken for that purpose. We are running 12.2(11)T and T1 on a couple of routers that have the full array of traffic, and although there definitely are some v4 multicast bugs they haven't been show-stoppers. (11) fixed a crasher multicast bug, and the only other crash we know of is 'show ip sdr', which is broken in all IOS releases AFAICT. I still don't recommend T images for critical production routers, but (11) does seem like a reasonable choice if you're willing to walk just a little bit close to the edge ;) Bill. From pekkas@netcore.fi Sat Nov 9 14:45:39 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Sat, 9 Nov 2002 16:45:39 +0200 (EET) Subject: [6bone] Cisco bug ? In-Reply-To: Message-ID: On Sat, 9 Nov 2002, Hans Goes wrote: > We're using a Cisco 7507 with a RSP4+ (256meg). > > 6B1.AMS7#ping 2001:820:0:1:1::2 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 2001:820:0:1:1::2, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 40/64/100 ms > 6B1.AMS7#conf t > Enter configuration commands, one per line. End with CNTL/Z. > 6B1.AMS7(config)#router bgp 1890 > 6B1.AMS7(config-router)#neighbor 2001:820:0:1:1::2 remote-as 16186 > 6B1.AMS7(config-router)#address-family ipv6 > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > % Activate the peer-group for the address family first Shouldn't the error message be self-evident or did I miss something; do you have something like: router bgp 1890 neighbor transit address-family ipv6 neighbor transit activate in the config already? > System image file is "slot0:rsp-pv-mz.122-0.5.T.bin" That's ages old. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From hans.goes@wcom.com Sat Nov 9 14:44:47 2002 From: hans.goes@wcom.com (Hans Goes) Date: Sat, 9 Nov 2002 14:44:47 +0000 (GMT) Subject: [6bone] Cisco bug ? In-Reply-To: <20021109133955.GA17098@gollum.gatel.net> Message-ID: Hi , Thanks to all who replied. We will take a closer look in the used IOS versions we use on the ipv6 network. I just forgot to activate the transit peer group indeed so it's working now :) This box is doing ipv6 only btw. Hans On Sat, 9 Nov 2002, Jan Czmok wrote: > Hans Goes (hgoes@eu.uu.net) wrote: > > Hi, > > > > We're using a Cisco 7507 with a RSP4+ (256meg). > > > > 6B1.AMS7#ping 2001:820:0:1:1::2 > > > > Type escape sequence to abort. > > Sending 5, 100-byte ICMP Echos to 2001:820:0:1:1::2, timeout is 2 seconds: > > !!!!! > > Success rate is 100 percent (5/5), round-trip min/avg/max = 40/64/100 ms > > 6B1.AMS7#conf t > > Enter configuration commands, one per line. End with CNTL/Z. > > 6B1.AMS7(config)#router bgp 1890 > > 6B1.AMS7(config-router)#neighbor 2001:820:0:1:1::2 remote-as 16186 > > 6B1.AMS7(config-router)#address-family ipv6 > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > > % Activate the peer-group for the address family first > > > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > > % Activate the peer-group for the address family first > > > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > > % Activate the peer-group for the address family first > > > > Any idea ? I've had this problem a couple of times but still the same > > problem. Sometimes a router reload helps... But that's not the way we want > > it :) > > > > System image file is "slot0:rsp-pv-mz.122-0.5.T.bin" > > > > it's quite easy: > > router bgp 1890ß > address-family ipv6 > neighbor transit activate > > then then the above... > > --jan > > > -- > Jan Ahrent Czmok - Senior Network Engineer - Access Networks > Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt > voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de > > > Hans Goes WorldCom EMEA Network Operations Joan Muyskenweg 24 1096 CJ Amsterdam Tel: +31 20 7112428 (Fax: 2455) V-Net: 711 2428 http://www.wcom.com/nl/ From raphit@noemie.org Sat Nov 9 14:59:59 2002 From: raphit@noemie.org (Raphael Bouaziz) Date: Sat, 9 Nov 2002 15:59:59 +0100 Subject: [6bone] Cisco bug ? In-Reply-To: <20021109145235.D94537@Space.Net>; from gert@space.net on Sat, Nov 09, 2002 at 02:52:35PM +0100 References: <20021109145235.D94537@Space.Net> Message-ID: <20021109155959.A95722@noemie.org> On Sat, Nov 09, 2002, Gert Doering wrote: > If the router is doing v4 plus v6 and eventually v4 multicast, I can't > recommend any image to you. All 12.2T images that I've heard of are > broken for that purpose. We run IPv4 and IPv6 on 12.2(2)T2, with OSPF plus BGP (for IPv4) and RIPng plus BGP4+ (for IPv6). We didn't experience major issues. Routers include Cisco 7120 and Cisco 7206VXR. By the way, there is some minor or "cosmetic" bugs, such as when I do a "show conf" on the router I get: ! router bgp 13193 [... IPv4 stuff ...] neighbor 2001:7A8:0:3:: remote-as 13193 neighbor 2001:7A8:0:3:: description * thevenin (iBGP) * neighbor 2001:7A8:0:3:: update-source Loopback0 no neighbor 2001:7A8:0:3:: activate [...] ! address-family ipv6 [...] neighbor 2001:7A8:0:3:: activate neighbor 2001:7A8:0:3:: send-community neighbor 2001:7A8:0:3:: soft-reconfiguration inbound [...] Obviously, I didn't enter a "no neighbor 2001:7A8:0:3:: activate" command in the BGP global configuration mode... But BGP4+ is working fine. Also, IPv6 is "almost" working on port-channel interfaces. Almost, because IGP activates on the interface and prefixes are received, but no traffic can go through the interface. But for now, using four IPv6 hops to reach a system when I use only three hops to reach the same system with its IPv4 address is not really critical. For me, the most important point is that today, IPv6 on the routers is not disturbing the IPv4 "production" traffic. So this image serves my business ;-). -- Raphael Bouaziz. raphit@noemie.org - http://noemie.nerim.net/ Sysadmin Power Forever(TM). From tvo@EnterZone.Net Sat Nov 9 16:13:42 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Sat, 9 Nov 2002 11:13:42 -0500 (EST) Subject: [6bone] www.6bone.not In-Reply-To: <20021109135427.A1340@ping.be> Message-ID: I ran into issues with a CNAME address today myself. It was on my network and has always worked in the past. I am on vacation in Florida right now and was unable to http connect to nitrous.ipv6.enterzone.net. This was using the wifes laptop running XP. I could go to a command prompt and ping it just fine. If I put nitrous.cmh.ipv6.enterzone.net in the browser, everything worked just fine. Perhaps this is a problem with the resolver library in the Microsoft software. I have never had any issues reaching the site before but, then again, I hadn't tried from the wifes laptop either. --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | On Sat, 9 Nov 2002, Kurt Roeckx wrote: > On Sat, Nov 09, 2002 at 10:21:45AM +0800, Gav wrote: > > I have noticed that most 6bone and related sites quote the main information site as > > www.6bone.net , this does not and has not worked for some time. Should this not be changed to read > > http://6bone.net as this one works (or get the www.6bone.net working). > > www.6bone.net. 1H IN CNAME 6bone.net. > > Looks weird to me that 1 would work and the other not. > > > Kurt > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From tvo@EnterZone.Net Sat Nov 9 16:15:07 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Sat, 9 Nov 2002 11:15:07 -0500 (EST) Subject: [6bone] Cisco bug ? In-Reply-To: Message-ID: You need to activate the PEER GROUP first! Exactly what the error message is telling you. --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | On Sat, 9 Nov 2002, Hans Goes wrote: > Hi, > > We're using a Cisco 7507 with a RSP4+ (256meg). > > 6B1.AMS7#ping 2001:820:0:1:1::2 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 2001:820:0:1:1::2, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 40/64/100 ms > 6B1.AMS7#conf t > Enter configuration commands, one per line. End with CNTL/Z. > 6B1.AMS7(config)#router bgp 1890 > 6B1.AMS7(config-router)#neighbor 2001:820:0:1:1::2 remote-as 16186 > 6B1.AMS7(config-router)#address-family ipv6 > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > % Activate the peer-group for the address family first > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > % Activate the peer-group for the address family first > > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 activate > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 remote-as 16186 > 6B1.AMS7(config-router-af)#neighbor 2001:820:0:1:1::2 peer-group transit > % Activate the peer-group for the address family first > > Any idea ? I've had this problem a couple of times but still the same > problem. Sometimes a router reload helps... But that's not the way we want > it :) > > System image file is "slot0:rsp-pv-mz.122-0.5.T.bin" > > > Hans > > WorldCom > EMEA Network Operations > Joan Muyskenweg 24 > 1096 CJ Amsterdam > > Tel: +31 20 7112428 (Fax: 2455) > V-Net: 711 2428 > http://www.wcom.com/nl/ > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From nicolas.deffayet@ndsoftware.net Sat Nov 9 16:36:20 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 09 Nov 2002 17:36:20 +0100 Subject: [6bone] best OS for ipv6 router. In-Reply-To: References: Message-ID: <1036859780.26606.5192.camel@wks1.fr.corp.ndsoftware.com> On Sat, 2002-11-09 at 12:39, Abdul Basit wrote: Hello, > What's the best OS to be run as ipv6 router ? > linux or freebsd (usagi or kame), from the facts > we observe kame is mature(more stable) than USAGI? > By the means of libc, does glibc supports most > of things described in sockets programming rfc's ? > or freebsd libc ? for example , i'm not still able > to get exim to listen on USAGI ipv6 sockets or bind9. > exim4 works on plain linux ipv6 support but not on usagi > (as far as my experience). > > In short, for an instance if you want to run a super duper > IPv6 router what OS you should use(linux,freebsd) ? I'm not > talking about cisco routers. Our new routers use FreeBSD 4.7 with KAME. Why we use now FreeBSD with KAME for our routers: -> FreeBSD with KAME support routing of IPv6 multicast, Linux with USAGI don't support it. -> FreeBSD is design for do routing and have more routing fonctions, with Linux you can get netlink errors with Zebra. -> FreeBSD is more stable than Linux. (Yesterday our router under Linux crashed) -> FreeBSD with KAME have a better IPv6 support than Linux with USAGI -> FreeBSD with KAME support IPv6 QoS (ALTQ) Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From jochen@scram.de Sat Nov 9 17:07:30 2002 From: jochen@scram.de (Jochen Friedrich) Date: Sat, 9 Nov 2002 18:07:30 +0100 (CET) Subject: [6bone] best OS for ipv6 router. In-Reply-To: <1036859780.26606.5192.camel@wks1.fr.corp.ndsoftware.com> Message-ID: Hi Nicolas, if you need to do packet filtering on the router, OpenBSD seems to be even better than FreeBSD as they have the only working stateful filter for IPv6, IIRC. --jochen From itojun@iijlab.net Sat Nov 9 17:17:05 2002 From: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Sun, 10 Nov 2002 02:17:05 +0900 Subject: [6bone] best OS for ipv6 router. In-Reply-To: nicolas.deffayet's message of 09 Nov 2002 17:36:20 +0100. <1036859780.26606.5192.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021109171705.7400A7AF@starfruit.itojun.org> >Our new routers use FreeBSD 4.7 with KAME. > >Why we use now FreeBSD with KAME for our routers: > >-> FreeBSD with KAME support routing of IPv6 multicast, Linux with USAGI >don't support it. > >-> FreeBSD is design for do routing and have more routing fonctions, >with Linux you can get netlink errors with Zebra. > >-> FreeBSD is more stable than Linux. (Yesterday our router under Linux >crashed) > >-> FreeBSD with KAME have a better IPv6 support than Linux with USAGI > >-> FreeBSD with KAME support IPv6 QoS (ALTQ) > >Best Regards, note, however, we KAME team DO NOT recommend to run KAME-patched *BSD in production environment, as documented in kame README files (it has too much experimental stuff = unstable, and KAME tree don't follow security alerts issued by *BSD) for production use, i'd suggest using stock FreeBSD 4.7. (and if there's any problem in 4.7 itself, send bug reports!) itojun From tjc@ecs.soton.ac.uk Sat Nov 9 17:59:40 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Sat, 9 Nov 2002 17:59:40 +0000 Subject: [6bone] www.6bone.not In-Reply-To: <1667.81.6.207.27.1036848711.squirrel@webmail.kewlio.net> References: <001201c2879f$a1d2ece0$e1feafca@andrew> <20021109094609.GB736@login.ecs.soton.ac.uk> <1667.81.6.207.27.1036848711.squirrel@webmail.kewlio.net> Message-ID: <20021109175940.GE4488@login.ecs.soton.ac.uk> Oh yes, the guys at BT Exact are great, but ultimately a consumer service would be run by the same "sucky" people who run OPenworld :( In fact we work with BT Exact in a number of projects, and the Openworld DSL mess is not their fault! Do you have any other good UK recommendations for DSL (please reply off list if you do :) Tim On Sat, Nov 09, 2002 at 01:31:51PM -0000, Daniel Austin wrote: > Hi Tim, > > Luckily IPv6 at BT is currently handled by BTexact, not BTopenworld ;-) > Their ipv6 team are very helpful and i've had zero problems from them. > > Sadly, their DSL sucks :) > > > Daniel. > > > Or maybe like me he's on BT Openworld's UK DSL service, which has been > > screwed up for 10 days now, witrh customers unable to reach a lare chunk > > of web sites. I despair for such an ISP deploying IPv6 when they can't > > even support IPv4. > > > > Tim > > > > On Sat, Nov 09, 2002 at 11:25:14AM +0800, Madrigallos, Andrew G. wrote: > >> To Gav, > >> > >> Maybe there is a problem on your DNS, www.6bone.net is working fine. > >> > >> Andrew > >> ----- Original Message ----- > >> From: Gav > >> To: 6bone@mailman.isi.edu > >> Sent: Saturday, November 09, 2002 10:21 Andrew > >> Subject: [6bone] www.6bone.not > >> > >> > >> Hi All, > >> > >> Not an emergency I know but if we can't get the front end to the > >> public right! :- > >> > >> I have noticed that most 6bone and related sites quote the main > >> information site as www.6bone.net , this does not and has not worked > >> for some time. Should this not be changed to read http://6bone.net > >> as this one works (or get the www.6bone.net working). > >> Also www.6bone.com redirects to Plexos.com - a web design > >> Company, which > >> contains little more than 1 page of links to other 6bone sites, > >> whats going on there then? > >> > >> Regards, > >> > >> Gavin... > >> > >> > >> --- > >> Checked for Viruses (Viri) , Gav... > >> Checked by AVG anti-virus system (http://www.grisoft.com). > >> Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > > -- > > > With Thanks, > > Daniel Austin, > Managing Director, > Kewlio.net Limited. > > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone From john@sixgirls.org Sat Nov 9 19:11:34 2002 From: john@sixgirls.org (John Klos) Date: Sat, 9 Nov 2002 14:11:34 -0500 (EST) Subject: [6bone] best OS for ipv6 router. In-Reply-To: Message-ID: Hi, > if you need to do packet filtering on the router, OpenBSD seems to be even > better than FreeBSD as they have the only working stateful filter for > IPv6, IIRC. NetBSD's ipfilter does IPv6, and any old hardware will do (older Sun hardware, one can argue, will probably be more stable than a run-of-the-mill PC, for example). John Klos Sixgirls Computing Labs From jeanb@jeanb-net.com Sat Nov 9 20:42:31 2002 From: jeanb@jeanb-net.com (Jeanb) Date: Sat, 9 Nov 2002 21:42:31 +0100 Subject: [6bone] Where is NDSoftware pTLA allocation ? Message-ID: <004201c28830$9e9ef320$0201a8c0@Jeanb> This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C28839.00635B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I'm an IPv6-FR user (IPv6-FR depends on the NDSoftware IPv6 Network, IP and transit) and I see that NDSoftware should be granted their pTLA allocation. Why isn't the NDSoftware pTLA allocated ? Why isn't their pTLA listed in http://www.6bone.net/6bone_pTLA_list.html ? Will it be the next allocated : 3FFE:4013::/32 ? Is there a reason to this mystery ? Regards. Paux Jean-Benoit ------=_NextPart_000_0043_01C28839.00635B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello,
 
I'm an = IPv6-FR user=20 (IPv6-FR depends on the NDSoftware IPv6 Network, IP and = transit) =20 and I see that NDSoftware should be granted their pTLA allocation. = Why=20 isn't the NDSoftware pTLA allocated ? Why isn't their pTLA listed in http://www.6bone.net/6= bone_pTLA_list.html=20 ?
 
Will = it be the next=20 allocated : 3FFE:4013::/32 ?
Is = there a reason to=20 this mystery ?
 
Regards.
Paux=20 Jean-Benoit
------=_NextPart_000_0043_01C28839.00635B20-- From old_mc_donald@hotmail.com Sun Nov 10 02:33:00 2002 From: old_mc_donald@hotmail.com (Gav) Date: Sun, 10 Nov 2002 10:33:00 +0800 Subject: [6bone] www.6bone.not References: <240659DFBDD99C4299EF7483EAD70F24DB0C1B@RED-MSG-01.redmond.corp.microsoft.com> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C288A4.8AD53D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message ----- Original Message -----=20 From: Stewart Tansley=20 To: Gav=20 Sent: Saturday, November 09, 2002 10:50 AM Subject: RE: [6bone] www.6bone.not Gavin -- www.6bone.net works fine from here... Stewart Tansley Program Manager=20 http://www.microsoft.com/ipv6/=20 Hi Stewart & Everyone else who replied. It's working fine now. As I have IPv6 installed WinXP decided to resolve www.6bone.net to = its IPv6 address, and as I never had a tunnel configured it wouldn't reach it. Question for Stuart then,=20 This could present a problem for lots of Microsoft users if they = have XP with (accidentally or not)=20 the IPv6 stack installed. Even if a v4 version of a site exists, it = will not be looked for as the v6 address of the site has not been reached, by default it seems that if a v6 = version exists it will look for that and if not found will return an error. This is my interpretation of the recent events I have experienced. :) Regards, Gav... --- Checked for Viruses (Viri) , Gav... Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 ------=_NextPart_000_0027_01C288A4.8AD53D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
 
----- Original Message -----
From:=20 Stewart=20 Tansley
To: Gav
Sent: Saturday, November 09, = 2002 10:50=20 AM
Subject: RE: [6bone] www.6bone.not

Gavin -- www.6bone.net works fine from=20 here...
 
Stewart Tansley
Program=20 Manager
http://www.microsoft.com/ipv6/=20
Hi Stewart & Everyone else who = replied.
 
It's working fine now.
As I have IPv6 installed WinXP decided to = resolve www.6bone.net to its IPv6 address, = and as I=20 never
had a tunnel configured it wouldn't reach = it.
 
Question for Stuart then,
 
This could present a problem for lots of = Microsoft users=20 if they have XP with (accidentally or not)
the IPv6 stack installed. Even if a v4 version = of a site=20 exists, it will not be looked for as the v6 address
of the site has not been reached, by default = it seems that=20 if a v6 version exists it will look for that and
if not found will return an = error.
 
This is my interpretation of the recent events = I have=20 experienced.
 
:)
 
Regards,
 
Gav...
 
 

---
Checked for Viruses (Viri) , = Gav...
Checked=20 by AVG anti-virus system (http://www.grisoft.com).
Version: = 6.0.410 / Virus Database: 231 - Release Date:=20 31/10/2002
------=_NextPart_000_0027_01C288A4.8AD53D80-- From old_mc_donald@hotmail.com Sun Nov 10 04:08:42 2002 From: old_mc_donald@hotmail.com (Gav) Date: Sun, 10 Nov 2002 12:08:42 +0800 Subject: [6bone] IPv6 connection + website. References: <240659DFBDD99C4299EF7483EAD70F24EFBC2C@RED-MSG-01.redmond.corp.microsoft.com> Message-ID: ----- Original Message ----- From: "Stewart Tansley" Sent: Saturday, November 09, 2002 12:11 PM Subject: RE: [6bone] IPv6 connection + website. > Windows .NET Server 2003 family in beta is also available, as a free > download. Yes, I have registered for it, auto email says it may be a few weeks before I get it or not. I wont hold my breath though as I am not a big Co /Org /Edu. Thanks Anyway. > Stewart Tansley > Program Manager > http://www.microsoft.com/ipv6/ > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > --- Checked for Viruses (Viri) , Gav... Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.410 / Virus Database: 231 - Release Date: 31/10/2002 From fink@es.net Mon Nov 11 02:00:32 2002 From: fink@es.net (Bob Fink) Date: Sun, 10 Nov 2002 18:00:32 -0800 Subject: [6bone] NDSOFTWARE pTLA review In-Reply-To: <20021109113016.GA10687@bfib.colo.bit.nl> References: <5.1.0.14.0.20021108152241.031ccea8@imap2.es.net> <5.1.0.14.0.20021108152241.031ccea8@imap2.es.net> Message-ID: <5.1.0.14.0.20021110175017.035816c0@imap2.es.net> Pim, At 12:30 PM 11/9/2002 +0100, Pim van Pelt wrote: >Dear committee members, > >| After careful review, and further questions asked of, and answered by, >| Nicolas Deffayet, the panel unanimously agrees that NDSOFTWARE should be >| granted their pTLA allocation. > >Such a decision was made only after very careful consideration and I will >no longer doubt the validity of DEFFAYETs pTLA that will be granted to him >and/or NDSoftware. I trust your good judgment in this case, even though >we disagree. Thanks for the time you spent on the matter. > >I think Bob makes a valid point that we should revise RFC2772 to make >the pTLA allocation request less ambiguous in the future. Let's procede >with 6BONE and keep this list at the high quality standard that it's >always been ! Thanks! I appreciate your support. Bob From fink@es.net Mon Nov 11 02:44:33 2002 From: fink@es.net (Bob Fink) Date: Sun, 10 Nov 2002 18:44:33 -0800 Subject: [6bone] 6bone pTLA 3FFE:4013::/32 allocated to NDSOFTWARE Message-ID: <5.1.0.14.0.20021110184240.03185b00@imap2.es.net> NDSOFTWARE has been allocated pTLA 3FFE:4013::/32 having finished its review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to hostmaster@ep.net.] Thanks, Bob From tvo@EnterZone.Net Mon Nov 11 16:34:18 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 11 Nov 2002 11:34:18 -0500 (EST) Subject: [6bone] abuse notification (fwd) Message-ID: OK people. For crying out loud. If you see a 5Mb/s spike on v6 network, what would this indicate to you? To me, it indicates that some little shit needs to be hunted down and beaten down into little turd pieces. On top of that, if you terminate someone for DoS type activity, please do the rest of the v6 community a favor and let us know. We've got enough of this garbage on v4 without allowing it in v6. Our network was involved (in a transit capacity) in a v6 DoS last from about 0430GMT - 1030GMT. I was onsite at Kennedy Space Center during this window and obviously, my pager was not functioning in that environment. When I got off the plane this morning, I got the page. Anyway, if you have some little puke abuse your (and MY) network, kill them and let us know who they are so none of US give them service either --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | ---------- Forwarded message ---------- Date: Mon, 11 Nov 2002 11:37:08 +0100 From: Jan Oravec To: ipv6-support@mimos.my, ina@mimos.my, roha@mimos.my Cc: tvo@EnterZone.Net, yap@yapsoft.it, noc@xs26.net Subject: abuse notification Dear operator at MIMOS-MY, Our NOC detected about 5 Mbps ICMP flood originating from your network at 11-th November 10:59 CET. 11:11:06.357760 3ffe:80d0:50:2::1ffd > 3ffe:80ee:5e7::c:1992: icmp6: echo request We have received the flood via ENTERZONE peering at our New York PoP. The traffic was destinated to one of our user. In order to protect our transatlantic network paths, we have been forced to temporarily shutdown our peering with ENTERZONE. We will re-enable it as soon as traffic is stopped. We kindly ask you to solve this issue. Copy of this mail has been sent to ENTERZONE NOC and technical contact of our user. Best Regards, -- Jan Oravec project coordinator XS26 - 'Access to IPv6' http://www.xs26.net jan.oravec@xs26.net From pekkas@netcore.fi Mon Nov 11 19:20:30 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 11 Nov 2002 21:20:30 +0200 (EET) Subject: [6bone] abuse notification (fwd) In-Reply-To: Message-ID: On Mon, 11 Nov 2002, John Fraizer wrote: > OK people. For crying out loud. If you see a 5Mb/s spike on v6 network, > what would this indicate to you? To me, it indicates that some little > shit needs to be hunted down and beaten down into little turd pieces. [...] To me, it indicates a small fraction of our v6 newsfeed traffic. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From tvo@EnterZone.Net Mon Nov 11 21:15:55 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 11 Nov 2002 16:15:55 -0500 (EST) Subject: [6bone] abuse notification (fwd) In-Reply-To: Message-ID: On Mon, 11 Nov 2002, Pekka Savola wrote: > On Mon, 11 Nov 2002, John Fraizer wrote: > > OK people. For crying out loud. If you see a 5Mb/s spike on v6 network, > > what would this indicate to you? To me, it indicates that some little > > shit needs to be hunted down and beaten down into little turd pieces. > [...] > > To me, it indicates a small fraction of our v6 newsfeed traffic. > > -- > Pekka Savola "Tell me of difficulties surmounted, Pekka, the operative word here is SPIKE. IE; Out of the ordinary or uncharacteristic. --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | From owens@nysernet.org Mon Nov 11 21:53:31 2002 From: owens@nysernet.org (Bill Owens) Date: Mon, 11 Nov 2002 16:53:31 -0500 Subject: [6bone] abuse notification (fwd) In-Reply-To: References: Message-ID: At 16:15 -0500 11/11/02, John Fraizer wrote: >On Mon, 11 Nov 2002, Pekka Savola wrote: > > To me, it indicates a small fraction of our v6 newsfeed traffic. > >Pekka, the operative word here is SPIKE. IE; Out of the ordinary or >uncharacteristic. One could imagine that a routing change could redirect someone's v6 newsfeed across a new network that was used to the usual IPv6 traffic loads (tens of kbps), and cause some suprise. Obviously that was not the case here, since the other end reported that the packets were echo requests. But it does make the point that a network operator used to having almost no v6 traffic might be quite suprised should they suddenly see even a steady traffic load. The initial reaction shouldn't be to assume DoS without knowing more about the nature of the traffic. . . Bill. From michel@arneill-py.sacramento.ca.us Mon Nov 11 22:01:32 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 11 Nov 2002 14:01:32 -0800 Subject: [6bone] NDSOFTWARE pTLA review Message-ID: <2B81403386729140A3A899A8B39B04640BD33A@server2000> > Pim van Pelt wrote: > I think Bob makes a valid point that we should revise > RFC2772 to make the pTLA allocation request less > ambiguous in the future. Let's procede with 6BONE and > keep this list at the high quality standard that it's > always been ! I would add to this that it would make a lot of sense to kill two birds with one stone and make this an opportunity for the move towards the RIRs. Michel. From hansolofalcon@worldnet.att.net Mon Nov 11 22:18:47 2002 From: hansolofalcon@worldnet.att.net (Gregg C Levine) Date: Mon, 11 Nov 2002 17:18:47 -0500 Subject: [6bone] abuse notification (fwd) In-Reply-To: Message-ID: Hello from Gregg C Levine Yes, John, you are quite right. That is the operative word. I certainly hope that you, and your staff, gave them a good thrashing over this stupidity that they are complaining about. I refuse to believe that your outfit is to blame here. I read the actual message that you forwarded to the list, and the facts don't add up. I could see the events of a high-jacking of an allocation, going on, but that insanity? It just does not make sense. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."  Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: 6bone-admin@mailman.isi.edu [mailto:6bone-admin@mailman.isi.edu] On > Behalf Of John Fraizer > Sent: Monday, November 11, 2002 4:16 PM > To: Pekka Savola > Cc: 6bone@ISI.EDU > Subject: Re: [6bone] abuse notification (fwd) > > > On Mon, 11 Nov 2002, Pekka Savola wrote: > > > On Mon, 11 Nov 2002, John Fraizer wrote: > > > OK people. For crying out loud. If you see a 5Mb/s spike on v6 network, > > > what would this indicate to you? To me, it indicates that some little > > > shit needs to be hunted down and beaten down into little turd pieces. > > [...] > > > > To me, it indicates a small fraction of our v6 newsfeed traffic. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > > Pekka, the operative word here is SPIKE. IE; Out of the ordinary or > uncharacteristic. > > > --- > John Fraizer | High-Security Datacenter Services | > President | Dedicated circuits 64k - 155M OC3 | > EnterZone, Inc | Virtual, Dedicated, Colocation | > http://www.enterzone.net/ | Network Consulting Services | > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone From pasky@pasky.ji.cz Mon Nov 11 22:38:21 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Mon, 11 Nov 2002 23:38:21 +0100 Subject: [6bone] abuse notification (fwd) In-Reply-To: References: Message-ID: <20021111223821.GG2644@pasky.ji.cz> Dear diary, on Mon, Nov 11, 2002 at 08:20:30PM CET, I got a letter, where Pekka Savola told me, that... > On Mon, 11 Nov 2002, John Fraizer wrote: > > OK people. For crying out loud. If you see a 5Mb/s spike on v6 network, > > what would this indicate to you? To me, it indicates that some little > > shit needs to be hunted down and beaten down into little turd pieces. > [...] > > To me, it indicates a small fraction of our v6 newsfeed traffic. Well, the type of traffic matters a lot for us here. People running our (XS26') points of presence basically donate the bandwidth to us, and they are ready to support higher data flows (at least up to certain degree), even though these are still more than unusual in the today's v6 world. But we are careful when the traffic suddenly peaks dramatically and we usually carefully examine what's flowing through the wires - while it's ok for us to donate the bandwidth for regular v6 traffic, we don't feel like donating our bandwidth for ICMPv6 floods. -- Petr "Pasky" Baudis . This host is a black hole at HTTP wavelengths. GETs go in, and nothing comes out, not even Hawking radiation. -- Graaagh the Mighty on rec.games.roguelike.angband . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From tvo@EnterZone.Net Mon Nov 11 22:55:30 2002 From: tvo@EnterZone.Net (John Fraizer) Date: Mon, 11 Nov 2002 17:55:30 -0500 (EST) Subject: [6bone] abuse notification (fwd) In-Reply-To: Message-ID: On Mon, 11 Nov 2002, Bill Owens wrote: > At 16:15 -0500 11/11/02, John Fraizer wrote: > >On Mon, 11 Nov 2002, Pekka Savola wrote: > > > To me, it indicates a small fraction of our v6 newsfeed traffic. > > > >Pekka, the operative word here is SPIKE. IE; Out of the ordinary or > >uncharacteristic. > > One could imagine that a routing change could redirect someone's v6 > newsfeed across a new network that was used to the usual IPv6 traffic > loads (tens of kbps), and cause some suprise. Obviously that was not > the case here, since the other end reported that the packets were > echo requests. But it does make the point that a network operator > used to having almost no v6 traffic might be quite suprised should > they suddenly see even a steady traffic load. The initial reaction > shouldn't be to assume DoS without knowing more about the nature of > the traffic. . . > > Bill. OK. This brings on a very good point when it comes time to choose peers. It's a bad idea to accept transit from someone who can't handle your "normal" traffic, even if it is temporary "backup" transit. Why? Because if your NORMAL traffic is going to swamp their network, they are of no use to you as a transit peer and you are a liability to their network. As indicated though, this particular instance was ICMP based. The only role EnterZone played in this was as a transit AS. We did not characterization of traffic at all. XS26 simply cc'd us on the abuse notification because to mitigate the effects of the attack, they had to temporary shutdown our peering session. --- John Fraizer | High-Security Datacenter Services | President | Dedicated circuits 64k - 155M OC3 | EnterZone, Inc | Virtual, Dedicated, Colocation | http://www.enterzone.net/ | Network Consulting Services | From stansley@microsoft.com Tue Nov 12 02:44:53 2002 From: stansley@microsoft.com (Stewart Tansley) Date: Mon, 11 Nov 2002 18:44:53 -0800 Subject: [6bone] www.6bone.not Message-ID: <240659DFBDD99C4299EF7483EAD70F24EFBC34@RED-MSG-01.redmond.corp.microsoft.com> > As I have IPv6 installed WinXP decided to resolve www.6bone.net to its IPv6 address, and as I never had a tunnel configured it wouldn't reach it. > > Question for Stuart then, > This could present a problem for lots of Microsoft users if they have XP with (accidentally or not) the IPv6 stack installed. Even if a v4 version of a site exists, it will not be looked for as the v6 address of the site has not been reached, by default it seems that if a v6 version exists it will look for that and if not found will return an error. Gav -- IE6 does fall back to using IPv4 if the IPv6 connection is unsuccessful. IE6 (and other IPv6-savvy Windows apps) explicitly queries for both AAAA and A records from the DNS via the stack's call to the DNS client. The combined results from the DNS server are returned to the app in a list. It is the apps responsibility to cycle through the list. IE6 is written to do this correctly (i.e. try IPv6 addresses first, then IPv4), so it should by design fall back to using IPv4 if the IPv6 connection fails for some reason. If this is apparently not happening, it is likely a problem with either *both* transports to the web site, or the DNS server you are querying is not returning both AAAA and A records correctly. We have seen some of the latter. Stewart Tansley Program Manager http://www.microsoft.com/ipv6/ From fink@es.net Tue Nov 12 16:06:19 2002 From: fink@es.net (Bob Fink) Date: Tue, 12 Nov 2002 08:06:19 -0800 Subject: [6bone] RFC2772 rewrite Message-ID: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> 6bone Folk, As noted last week, the pTLA review panel felt strongly that it was time to rewrite/update RFC2772. Thus we would like to call for ideas/suggestions/issues for the rewrite. Please send your comments to the list, or to one of the panel folk if you want to comment privately. Also, if it would be useful to have an ad hoc 6bone meeting in Atlanta, please let us know. Although I will not be at this IETF, someone else from the panel could lead the discussion. Regarding 6bone operating issues, please look at Pekka Savola's 6bone-mess draft to see if you think any/all of it should be included in the RFC2772 rewrite: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Moving from 6bone to IPv6 Internet > Author(s) : P. Savola > Filename : draft-savola-v6ops-6bone-mess-00.txt > Pages : 13 > Date : 2002-10-24 > >Currently, IPv6 Internet is, globally considered, inseparable from >the 6bone network. The 6bone has been built as a tighly meshed >tunneled topology. As the number of participants has grown, it has >become an untangible mess, hindering the real deployment of IPv6 due >to low quality of connections. This memo discusses the nature and >the state of 6bone/IPv6 Internet, points out problems and outlines a >few ways to start fixing them; also, some rough operational >guidelines for different-sized organizations are presented. The most >important issues are: not offering transit to everyone and real >transit operators being needed to take a more active role. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt Thanks, Bob From mark@npsl.co.uk Tue Nov 12 17:00:15 2002 From: mark@npsl.co.uk (Mark Weaver) Date: Tue, 12 Nov 2002 17:00:15 -0000 Subject: [6bone] RFC2772 rewrite In-Reply-To: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> Message-ID: The link gives me a 404, from a couple of places (over IPv4 :)... > -----Original Message----- > From: 6bone-admin@mailman.isi.edu [mailto:6bone-admin@mailman.isi.edu]On > Behalf Of Bob Fink > Sent: 12 November 2002 16:06 > To: 6BONE List > Cc: David Kessens; Robert Rockell; Gert Doering; Jun-ichiro itojun > Hagino; Bob Fink > Subject: [6bone] RFC2772 rewrite > > > 6bone Folk, > > As noted last week, the pTLA review panel felt strongly that it > was time to > rewrite/update RFC2772. > > Thus we would like to call for ideas/suggestions/issues for the rewrite. > Please send your comments to the list, or to one of the panel folk if you > want to comment privately. > > Also, if it would be useful to have an ad hoc 6bone meeting in Atlanta, > please let us know. Although I will not be at this IETF, someone > else from > the panel could lead the discussion. > > > Regarding 6bone operating issues, please look at Pekka Savola's > 6bone-mess > draft to see if you think any/all of it should be included in the RFC2772 > rewrite: > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Moving from 6bone to IPv6 Internet > > Author(s) : P. Savola > > Filename : draft-savola-v6ops-6bone-mess-00.txt > > Pages : 13 > > Date : 2002-10-24 > > > >Currently, IPv6 Internet is, globally considered, inseparable from > >the 6bone network. The 6bone has been built as a tighly meshed > >tunneled topology. As the number of participants has grown, it has > >become an untangible mess, hindering the real deployment of IPv6 due > >to low quality of connections. This memo discusses the nature and > >the state of 6bone/IPv6 Internet, points out problems and outlines a > >few ways to start fixing them; also, some rough operational > >guidelines for different-sized organizations are presented. The most > >important issues are: not offering transit to everyone and real > >transit operators being needed to take a more active role. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt > > > Thanks, > > Bob > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From celinn@mtu.edu Tue Nov 12 17:23:53 2002 From: celinn@mtu.edu (Christopher Linn) Date: Tue, 12 Nov 2002 12:23:53 -0500 Subject: [6bone] RFC2772 rewrite In-Reply-To: ; from mark@npsl.co.uk on Tue, Nov 12, 2002 at 05:00:15PM -0000 References: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> Message-ID: <20021112122353.A27931@mtu.edu> On Tue, Nov 12, 2002 at 05:00:15PM -0000, Mark Weaver wrote: > The link gives me a 404, from a couple of places (over IPv4 :)... [...] > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-01.txt seems to work ;*> chris -- Christopher Linn, (celinn at mtu.edu) | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From uriah_pollock@mentorg.com Tue Nov 12 17:26:32 2002 From: uriah_pollock@mentorg.com (Pollock, Uriah) Date: Tue, 12 Nov 2002 11:26:32 -0600 Subject: [6bone] RFC2772 rewrite Message-ID: Try this one: http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-01.txt -----Original Message----- From: Mark Weaver [mailto:mark@npsl.co.uk] Sent: Tuesday, November 12, 2002 11:00 AM To: 6BONE List Subject: RE: [6bone] RFC2772 rewrite The link gives me a 404, from a couple of places (over IPv4 :)... > -----Original Message----- > From: 6bone-admin@mailman.isi.edu [mailto:6bone-admin@mailman.isi.edu]On > Behalf Of Bob Fink > Sent: 12 November 2002 16:06 > To: 6BONE List > Cc: David Kessens; Robert Rockell; Gert Doering; Jun-ichiro itojun > Hagino; Bob Fink > Subject: [6bone] RFC2772 rewrite > > > 6bone Folk, > > As noted last week, the pTLA review panel felt strongly that it > was time to > rewrite/update RFC2772. > > Thus we would like to call for ideas/suggestions/issues for the rewrite. > Please send your comments to the list, or to one of the panel folk if you > want to comment privately. > > Also, if it would be useful to have an ad hoc 6bone meeting in Atlanta, > please let us know. Although I will not be at this IETF, someone > else from > the panel could lead the discussion. > > > Regarding 6bone operating issues, please look at Pekka Savola's > 6bone-mess > draft to see if you think any/all of it should be included in the RFC2772 > rewrite: > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Moving from 6bone to IPv6 Internet > > Author(s) : P. Savola > > Filename : draft-savola-v6ops-6bone-mess-00.txt > > Pages : 13 > > Date : 2002-10-24 > > > >Currently, IPv6 Internet is, globally considered, inseparable from > >the 6bone network. The 6bone has been built as a tighly meshed > >tunneled topology. As the number of participants has grown, it has > >become an untangible mess, hindering the real deployment of IPv6 due > >to low quality of connections. This memo discusses the nature and > >the state of 6bone/IPv6 Internet, points out problems and outlines a > >few ways to start fixing them; also, some rough operational > >guidelines for different-sized organizations are presented. The most > >important issues are: not offering transit to everyone and real > >transit operators being needed to take a more active role. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt > > > Thanks, > > Bob > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone From pim@ipng.nl Tue Nov 12 17:38:47 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 12 Nov 2002 18:38:47 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: References: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> Message-ID: <20021112173847.GA6703@bfib.colo.bit.nl> On Tue, Nov 12, 2002 at 05:00:15PM -0000, Mark Weaver wrote: | The link gives me a 404, from a couple of places (over IPv4 :)... That's probably because it's at version 01 already :-) http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-01.txt groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From pekkas@netcore.fi Tue Nov 12 17:58:12 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 12 Nov 2002 19:58:12 +0200 (EET) Subject: [6bone] RFC2772 rewrite In-Reply-To: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> Message-ID: On Tue, 12 Nov 2002, Bob Fink wrote: > Thus we would like to call for ideas/suggestions/issues for the rewrite. > Please send your comments to the list, or to one of the panel folk if you > want to comment privately. > > Also, if it would be useful to have an ad hoc 6bone meeting in Atlanta, > please let us know. Although I will not be at this IETF, someone else from > the panel could lead the discussion. Yes, I believe such a meeting could be useful. A more extensive discussion, possibly around problems/solutions in my draft (and other topics) would be possible -- there may be a little time allocated for this in the v6ops meeting, but I believe the time is probably a scarce resource there. > Regarding 6bone operating issues, please look at Pekka Savola's 6bone-mess > draft to see if you think any/all of it should be included in the RFC2772 > rewrite: Note that the revision number is now -01 (already! :-). > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Moving from 6bone to IPv6 Internet > > Author(s) : P. Savola > > Filename : draft-savola-v6ops-6bone-mess-00.txt > > Pages : 13 > > Date : 2002-10-24 > > > >Currently, IPv6 Internet is, globally considered, inseparable from > >the 6bone network. The 6bone has been built as a tighly meshed > >tunneled topology. As the number of participants has grown, it has > >become an untangible mess, hindering the real deployment of IPv6 due > >to low quality of connections. This memo discusses the nature and > >the state of 6bone/IPv6 Internet, points out problems and outlines a > >few ways to start fixing them; also, some rough operational > >guidelines for different-sized organizations are presented. The most > >important issues are: not offering transit to everyone and real > >transit operators being needed to take a more active role. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt > > > Thanks, > > Bob > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pim@ipng.nl Tue Nov 12 17:59:50 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 12 Nov 2002 18:59:50 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> References: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> Message-ID: <20021112175950.GA7250@bfib.colo.bit.nl> | Thus we would like to call for ideas/suggestions/issues for the rewrite. | Please send your comments to the list, or to one of the panel folk if you | want to comment privately. See below. | Also, if it would be useful to have an ad hoc 6bone meeting in Atlanta, | please let us know. Although I will not be at this IETF, someone else from | the panel could lead the discussion. I'm sorry to say that I do not frequently travel outside of the European continent, but shall we have a discussion at the upcoming RIPE meeting in Amsterdam, early 2003 ? We can take some coffeetime and get together. Regarding the 2772 rewrite, here's what comes to mind: * Should we have an upper bound in time in which one can operate a pTLA ? This will then stress the experimental nature of the allocation. * Should we have people running a pTLA next to their RIR space return their allocation to 6BONE ? * I think we should verify the existance of a founded company that will be the holder of the allocation. This might come in handy when/if we have a doubtful indivudual/company requesting space. I do not support individuals having globally routable IPv6 space. * Should there be any form of Common Sense Peering, eg recommendations for filtering and tunneling. * Should we seperate the 6BONE cloud from the production IPv6 cloud ? This is not really an RFC2772 issue, but does come to mind. While the Netherlands is getting more and more IPv6 aware (20 or so commercial entities out of 140 at AMS-IX are connecting right now), and 'real' transit providers start offering service, I cannot yet offer stable IPv6 connectivity outside of this AMS-IX cloud. I have heard sounds of operators filtering out 3ffe::/16 due to its impact on general availablility of IPv6 to their customers. This deserves discussion! Also, what about the previous pTLA allocations and general database tidiness. Jeroen Massar has, on numerous occasions, brought old stuff to our attention, and perhaps his point on us cleaning the DB up is valid. Should people that have not been announcing their pTLA have it revoked ? Just some thoughts to kick off the discussion. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From rrockell@sprint.net Tue Nov 12 18:47:44 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 12 Nov 2002 13:47:44 -0500 (EST) Subject: [6bone] RFC2772 rewrite In-Reply-To: <20021112175950.GA7250@bfib.colo.bit.nl> Message-ID: ->Regarding the 2772 rewrite, here's what comes to mind: ->* Should we have an upper bound in time in which one can operate a pTLA ? ->This will then stress the experimental nature of the allocation. I would think that a periodic check on pTLA allocations, to make sure that those who have pTLA allocations are still -using them -using them correctly would be helpful. Not sure to set a bound on the allocation. For instance, as I have limitations keeping me from deploying a production IPv6 service, I would not want to be forced into using ARIN assigned space before I have to (so I can delegate it correctly when the time comes). ->* Should we have people running a pTLA next to their RIR space return ->their allocation to 6BONE ? Don't know how to treat this one. I think it is ok for people to have both. Perhaps we could try to push the RIR's to only delegate space if the company intends to use it :) ->* I think we should verify the existance of a founded company that will ->be the holder of the allocation. This might come in handy when/if we ->have a doubtful indivudual/company requesting space. I do not support ->individuals having globally routable IPv6 space. Agreed. We should put something specific into the qualifications. ->* Should there be any form of Common Sense Peering, eg recommendations ->for filtering and tunneling. Agreed. Perhaps we should come up with quantitative numbers for tunnel latency, AS-hops, etc... Or should we just use generalized guidelines? As a more militant member of the 6bone, I'd like something quantitative, so we can take action when a pTLA violates the rules :) ->* Should we seperate the 6BONE cloud from the production IPv6 cloud ? This ->is not really an RFC2772 issue, but does come to mind. Don't know that we can influence this from the NGTRANS working group... ->While the Netherlands is getting more and more IPv6 aware (20 or so commercial ->entities out of 140 at AMS-IX are connecting right now), and 'real' ->transit providers start offering service, I cannot yet offer stable IPv6 ->connectivity outside of this AMS-IX cloud. I have heard sounds of operators ->filtering out 3ffe::/16 due to its impact on general availablility of ->IPv6 to their customers. This deserves discussion! So we fix the 6bone, or we cancel it... I think we should fix it. There is still transition testing that needs to take place, and it is easier to renumber/re-build/re-deploy the 6bone than it is to do the same with a production network :) ->Also, what about the previous pTLA allocations and general database ->tidiness. Jeroen Massar has, on numerous occasions, brought old stuff to ->our attention, and perhaps his point on us cleaning the DB up is valid. ->Should people that have not been announcing their pTLA have it revoked ? Agreed. ->Just some thoughts to kick off the discussion. -> ->groet, ->Pim -> ->-- ->---------- - - - - -+- - - - - ---------- ->Pim van Pelt Email: pim@ipng.nl ->http://www.ipng.nl/ IPv6 Deployment ->----------------------------------------------- -> From nicolas.deffayet@ndsoftware.net Tue Nov 12 20:28:17 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 12 Nov 2002 21:28:17 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> References: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> Message-ID: <1037132897.660.480.camel@wks1.fr.corp.ndsoftware.com> On Tue, 2002-11-12 at 17:06, Bob Fink wrote: 6bone Folk, > Thus we would like to call for ideas/suggestions/issues for the rewrite. > Please send your comments to the list, or to one of the panel folk if you > want to comment privately. I think that it can be a good idea to add this to RFC2772: - The pTLA Applicant must have a valid public ASN (no private or no allocated ASN). => a pTLA have been allocated with a no allocated ASN http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page17.html - The pTLA Applicant must have 2 transits. => a pTLA is for be independent of a upstream - The pTLA Applicant must use filter http://www.space.net/~gert/RIPE/ipv6-filters.html http://noc.ndsoftwarenet.com/docs/route-filtering.php => See Gert Doring's presentation: http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page14.html http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page15.html - The pTLA Applicant must reply to technical problems within 24 hours. => don't forgot AS1654... http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page18.html Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From nicolas.deffayet@ndsoftware.net Tue Nov 12 21:04:29 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 12 Nov 2002 22:04:29 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: References: Message-ID: <1037135069.672.531.camel@wks1.fr.corp.ndsoftware.com> On Tue, 2002-11-12 at 19:47, Robert J. Rockell wrote: > ->Also, what about the previous pTLA allocations and general database > ->tidiness. Jeroen Massar has, on numerous occasions, brought old stuff to > ->our attention, and perhaps his point on us cleaning the DB up is valid. > ->Should people that have not been announcing their pTLA have it revoked ? > > Agreed. Agreed too. For whois.6bone.net: -> activate mnt-lower feature -> add route object for register announced routes -> add aut-num object for register IPv6 peers Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From gert@space.net Tue Nov 12 21:29:14 2002 From: gert@space.net (Gert Doering) Date: Tue, 12 Nov 2002 22:29:14 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: ; from rrockell@sprint.net on Tue, Nov 12, 2002 at 01:47:44PM -0500 References: <20021112175950.GA7250@bfib.colo.bit.nl> Message-ID: <20021112222914.Q94537@Space.Net> Hi, On Tue, Nov 12, 2002 at 01:47:44PM -0500, Robert J. Rockell wrote: > ->* Should we have people running a pTLA next to their RIR space return > ->their allocation to 6BONE ? > > Don't know how to treat this one. I think it is ok for people to have both. > Perhaps we could try to push the RIR's to only delegate space if the company > intends to use it :) Well, this is one of the criteria for allocating RIR space at all - if the company intends to allocate 200 /48s to end sites over the next two years. (Neither "200" nor "two years" are checked very strictly right now, but it's the written rule). [..] > ->* Should there be any form of Common Sense Peering, eg recommendations > ->for filtering and tunneling. > > Agreed. Perhaps we should come up with quantitative numbers for tunnel > latency, AS-hops, etc... Or should we just use generalized guidelines? As > a more militant member of the 6bone, I'd like something quantitative, so we > can take action when a pTLA violates the rules :) I'm against hard quantitative rules for something that's constantly changing. The reason is that things that make sense "today" might be totally irresponsible "tomorrow" - the tunnel mess is part of that. Some years ago it was absolutely necessary to get connectivity, today it's doubtful, in a few years the tunnels should (hopefully) completely go away. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48540 (48282) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From pekkas@netcore.fi Tue Nov 12 22:22:38 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 13 Nov 2002 00:22:38 +0200 (EET) Subject: [6bone] RFC2772 rewrite In-Reply-To: <1037132897.660.480.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On 12 Nov 2002, Nicolas DEFFAYET wrote: > - The pTLA Applicant must have 2 transits. > > => a pTLA is for be independent of a upstream Do you mean: "The pTLA Applicant must have _only_ 2 transits" or "The pTLA Applicant must have at least 2 transits" or something like: "The pTLA Applicant must not acquire more than 2 transits" [my favourite :-)] Note -- I'm only half-joking here! Restricting the number of trensits a pTLA can have and provide transit for seems like a very sane approach to me! -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From nicolas.deffayet@ndsoftware.net Tue Nov 12 22:29:06 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 12 Nov 2002 23:29:06 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: References: Message-ID: <1037140146.665.551.camel@wks1.fr.corp.ndsoftware.com> On Tue, 2002-11-12 at 23:22, Pekka Savola wrote: > On 12 Nov 2002, Nicolas DEFFAYET wrote: > > - The pTLA Applicant must have 2 transits. > > > > => a pTLA is for be independent of a upstream > > Do you mean: "The pTLA Applicant must have at least 2 transits" Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From rrockell@sprint.net Tue Nov 12 23:44:07 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 12 Nov 2002 18:44:07 -0500 (EST) Subject: [6bone] RFC2772 rewrite In-Reply-To: <1037132897.660.480.camel@wks1.fr.corp.ndsoftware.com> Message-ID: agreed on all counts. 24 hours is one that I think some people might have problems with, but a good idea. Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On 12 Nov 2002, Nicolas DEFFAYET wrote: ->On Tue, 2002-11-12 at 17:06, Bob Fink wrote: ->6bone Folk, -> ->> Thus we would like to call for ideas/suggestions/issues for the rewrite. ->> Please send your comments to the list, or to one of the panel folk if you ->> want to comment privately. -> ->I think that it can be a good idea to add this to RFC2772: -> ->- The pTLA Applicant must have a valid public ASN (no private or no ->allocated ASN). -> ->=> a pTLA have been allocated with a no allocated ASN ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page17.html -> -> ->- The pTLA Applicant must have 2 transits. -> ->=> a pTLA is for be independent of a upstream -> -> ->- The pTLA Applicant must use filter ->http://www.space.net/~gert/RIPE/ipv6-filters.html ->http://noc.ndsoftwarenet.com/docs/route-filtering.php -> ->=> See Gert Doring's presentation: ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page14.html ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page15.html -> -> ->- The pTLA Applicant must reply to technical problems within 24 hours. -> ->=> don't forgot AS1654... ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page18.html -> -> ->Best Regards, -> ->Nicolas DEFFAYET, NDSoftware ->NOC Website: http://noc.ndsoftwarenet.com/ ->FNIX6: http://www.fnix6.net/ -> From Daniel Austin" Message-ID: <002101c28aa7$f33c9300$611c08d9@kewlio.net> Hi, I don't think that 24hours is bad for a *response* - maybe not resolution though. With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. ----- Original Message ----- From: "Robert J. Rockell" To: "Nicolas DEFFAYET" Cc: "Bob Fink" ; "6BONE List" <6bone@mailman.isi.edu>; "David Kessens" ; "Gert Doering" ; "Jun-ichiro itojun Hagino" Sent: Tuesday, November 12, 2002 11:44 PM Subject: Re: [6bone] RFC2772 rewrite > agreed on all counts. 24 hours is one that I think some people might have > problems with, but a good idea. > > Thanks > Rob Rockell > SprintLink > (+1) 703-689-6322 > ----------------------------------------------------------------------- > > On 12 Nov 2002, Nicolas DEFFAYET wrote: > > ->On Tue, 2002-11-12 at 17:06, Bob Fink wrote: > ->6bone Folk, > -> > ->> Thus we would like to call for ideas/suggestions/issues for the rewrite. > ->> Please send your comments to the list, or to one of the panel folk if you > ->> want to comment privately. > -> > ->I think that it can be a good idea to add this to RFC2772: > -> > ->- The pTLA Applicant must have a valid public ASN (no private or no > ->allocated ASN). > -> > ->=> a pTLA have been allocated with a no allocated ASN > ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page17.html > -> > -> > ->- The pTLA Applicant must have 2 transits. > -> > ->=> a pTLA is for be independent of a upstream > -> > -> > ->- The pTLA Applicant must use filter > ->http://www.space.net/~gert/RIPE/ipv6-filters.html > ->http://noc.ndsoftwarenet.com/docs/route-filtering.php > -> > ->=> See Gert Doring's presentation: > ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page14.html > ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page15.html > -> > -> > ->- The pTLA Applicant must reply to technical problems within 24 hours. > -> > ->=> don't forgot AS1654... > ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page18.html > -> > -> > ->Best Regards, > -> > ->Nicolas DEFFAYET, NDSoftware > ->NOC Website: http://noc.ndsoftwarenet.com/ > ->FNIX6: http://www.fnix6.net/ > -> > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From rrockell@sprint.net Wed Nov 13 00:13:40 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 12 Nov 2002 19:13:40 -0500 (EST) Subject: [6bone] RFC2772 rewrite In-Reply-To: <002101c28aa7$f33c9300$611c08d9@kewlio.net> Message-ID: Fair enough. If I don't hear anyone complain in 24 hours (good number to use) we'll stick that in there :) Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On Tue, 12 Nov 2002, Daniel Austin wrote: ->Hi, -> ->I don't think that 24hours is bad for a *response* - maybe not resolution though. -> -> ->With Thanks, -> ->Daniel Austin, ->Managing Director, ->kewlio.net Limited. -> -> ->----- Original Message ----- ->From: "Robert J. Rockell" ->To: "Nicolas DEFFAYET" ->Cc: "Bob Fink" ; "6BONE List" <6bone@mailman.isi.edu>; "David Kessens" ; "Gert Doering" ->; "Jun-ichiro itojun Hagino" ->Sent: Tuesday, November 12, 2002 11:44 PM ->Subject: Re: [6bone] RFC2772 rewrite -> -> ->> agreed on all counts. 24 hours is one that I think some people might have ->> problems with, but a good idea. ->> ->> Thanks ->> Rob Rockell ->> SprintLink ->> (+1) 703-689-6322 ->> ----------------------------------------------------------------------- ->> ->> On 12 Nov 2002, Nicolas DEFFAYET wrote: ->> ->> ->On Tue, 2002-11-12 at 17:06, Bob Fink wrote: ->> ->6bone Folk, ->> -> ->> ->> Thus we would like to call for ideas/suggestions/issues for the rewrite. ->> ->> Please send your comments to the list, or to one of the panel folk if you ->> ->> want to comment privately. ->> -> ->> ->I think that it can be a good idea to add this to RFC2772: ->> -> ->> ->- The pTLA Applicant must have a valid public ASN (no private or no ->> ->allocated ASN). ->> -> ->> ->=> a pTLA have been allocated with a no allocated ASN ->> ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page17.html ->> -> ->> -> ->> ->- The pTLA Applicant must have 2 transits. ->> -> ->> ->=> a pTLA is for be independent of a upstream ->> -> ->> -> ->> ->- The pTLA Applicant must use filter ->> ->http://www.space.net/~gert/RIPE/ipv6-filters.html ->> ->http://noc.ndsoftwarenet.com/docs/route-filtering.php ->> -> ->> ->=> See Gert Doring's presentation: ->> ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page14.html ->> ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page15.html ->> -> ->> -> ->> ->- The pTLA Applicant must reply to technical problems within 24 hours. ->> -> ->> ->=> don't forgot AS1654... ->> ->http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-ipv6-table/page18.html ->> -> ->> -> ->> ->Best Regards, ->> -> ->> ->Nicolas DEFFAYET, NDSoftware ->> ->NOC Website: http://noc.ndsoftwarenet.com/ ->> ->FNIX6: http://www.fnix6.net/ ->> -> ->> ->> _______________________________________________ ->> 6bone mailing list ->> 6bone@mailman.isi.edu ->> http://mailman.isi.edu/mailman/listinfo/6bone ->> -> From =?iso-8859-1?Q?J=F8rgen_Hovland?= Wed Nov 13 00:34:13 2002 From: =?iso-8859-1?Q?J=F8rgen_Hovland?= (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 13 Nov 2002 01:34:13 +0100 Subject: [6bone] RFC2772 rewrite References: Message-ID: <00b901c28aac$6f988630$1b29b3d5@hera> Im not sure if he meant IPv4 or IPv6 transits... I dont think any maximum or minimum requirements should be set. The maximum would restrict itself. Enterprise companies and institues often dont have ipv4 transit at all (and colocated servers doesnt have "transit" either). There are already pTLA-holders like this. On http://www.6bone.net/6bone_hookup.html it says only ISP's can apply for a pTLA. Maybe the definition of an ISP should be sorted out ? - Joergen Hovland ----- Original Message ----- From: "Pekka Savola" To: "Nicolas DEFFAYET" Cc: "Bob Fink" ; "6BONE List" <6bone@mailman.isi.edu>; "David Kessens" ; "Robert Rockell" ; "Gert Doering" ; "Jun-ichiro itojun Hagino" Sent: Tuesday, November 12, 2002 11:22 PM Subject: Re: [6bone] RFC2772 rewrite > On 12 Nov 2002, Nicolas DEFFAYET wrote: > > - The pTLA Applicant must have 2 transits. > > > > => a pTLA is for be independent of a upstream > > Do you mean: > > "The pTLA Applicant must have _only_ 2 transits" > > or > > "The pTLA Applicant must have at least 2 transits" > > or something like: > > "The pTLA Applicant must not acquire more than 2 transits" > [my favourite :-)] > > Note -- I'm only half-joking here! > > Restricting the number of trensits a pTLA can have and provide transit for > seems like a very sane approach to me! > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > From fink@es.net Wed Nov 13 02:24:26 2002 From: fink@es.net (Bob Fink) Date: Tue, 12 Nov 2002 18:24:26 -0800 Subject: [6bone] RFC2772 rewrite In-Reply-To: References: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> Message-ID: <5.1.0.14.0.20021112181333.0360f3e8@imap2.es.net> At 07:58 PM 11/12/2002 +0200, Pekka Savola wrote: >On Tue, 12 Nov 2002, Bob Fink wrote: > > Thus we would like to call for ideas/suggestions/issues for the rewrite. > > Please send your comments to the list, or to one of the panel folk if you > > want to comment privately. > > > > Also, if it would be useful to have an ad hoc 6bone meeting in Atlanta, > > please let us know. Although I will not be at this IETF, someone else from > > the panel could lead the discussion. > >Yes, I believe such a meeting could be useful. A more extensive >discussion, possibly around problems/solutions in my draft (and other >topics) would be possible -- there may be a little time allocated for this >in the v6ops meeting, but I believe the time is probably a scarce resource >there. We are not likely to allocate any v6ops time as it doesn't handle 6bone stuff like ngtrans used to (but hasn't recently as we ran out of time). I'll schedule a meeting in Atlanta. Thanks, Bob > > Regarding 6bone operating issues, please look at Pekka Savola's 6bone-mess > > draft to see if you think any/all of it should be included in the RFC2772 > > rewrite: > >Note that the revision number is now -01 (already! :-). > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > > > > > > > > Title : Moving from 6bone to IPv6 Internet > > > Author(s) : P. Savola > > > Filename : draft-savola-v6ops-6bone-mess-00.txt > > > Pages : 13 > > > Date : 2002-10-24 > > > > > >Currently, IPv6 Internet is, globally considered, inseparable from > > >the 6bone network. The 6bone has been built as a tighly meshed > > >tunneled topology. As the number of participants has grown, it has > > >become an untangible mess, hindering the real deployment of IPv6 due > > >to low quality of connections. This memo discusses the nature and > > >the state of 6bone/IPv6 Internet, points out problems and outlines a > > >few ways to start fixing them; also, some rough operational > > >guidelines for different-sized organizations are presented. The most > > >important issues are: not offering transit to everyone and real > > >transit operators being needed to take a more active role. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt > > > > > > Thanks, > > > > Bob > > > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From fink@es.net Wed Nov 13 02:54:22 2002 From: fink@es.net (Bob Fink) Date: Tue, 12 Nov 2002 18:54:22 -0800 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon Message-ID: <5.1.0.14.0.20021112185037.03630c40@imap2.es.net> 6bone Folk, By popular request ;-) there will be a 6bone meeting in Atlanta to discuss the RFC2772 rewrite. It will be held during the noon time break on Tuesday the 19th of December. To not conflict with room usage before and after, the meeting will convene at 11:45am and adjourn at 12.45pm. Rob Rockell will chair, and he will announce the meeting room to the list as soon as we can get the IETF Secretariat to assign the room, probably Monday the day before. Thanks, Bob From mhw@wittsend.com Wed Nov 13 04:15:18 2002 From: mhw@wittsend.com (Michael H. Warfield) Date: Tue, 12 Nov 2002 23:15:18 -0500 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon In-Reply-To: <5.1.0.14.0.20021112185037.03630c40@imap2.es.net> References: <5.1.0.14.0.20021112185037.03630c40@imap2.es.net> Message-ID: <20021113041518.GB5314@alcove.wittsend.com> --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 12, 2002 at 06:54:22PM -0800, Bob Fink wrote: > 6bone Folk, > By popular request ;-) there will be a 6bone meeting in Atlanta to discus= s=20 > the RFC2772 rewrite. It will be held during the noon time break on Tuesda= y=20 > the 19th of December. EXCUSE ME! The 19th of December? Surely you must mean the 19th of November. :-) Beside the fact that I don't think anyone is going to hang around THAT LONG in Atlanta (I live here so I'll still be kicking around) December 19th is on a Thursday (I know 'cause it's me birthday)... See you on the 19th of November in lovely Atlanta... Just jerking yer chain, Bob... > To not conflict with room usage before and after, the meeting will conven= e=20 > at 11:45am and adjourn at 12.45pm. > Rob Rockell will chair, and he will announce the meeting room to the list= =20 > as soon as we can get the IETF Secretariat to assign the room, probably= =20 > Monday the day before. > Thanks, > Bob Mike --=20 Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com /\/\|=3Dmhw=3D|\/\/ | (678) 463-0932 | http://www.wittsend.com/= mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! --qcHopEYAB45HaUaB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBPdHR1uHJS0bfHdRxAQE87AP9EKz9+UY1Wn1oOUjooN1NqDPsaDBMF0mI N1jAic4krnqmHk/cgkvnSPWxofYv1eP/tcXsCWzelHGgEdLJgWTggF+Htrovcr3W o6xq9QZcFTM4CBmjAEmHFuy4Bv3ckfh3bWffO6mV1GCE/2EjuvJ97D8XjW/Iv0yB 7q8b5tx+3fE= =dURV -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB-- From pekkas@netcore.fi Wed Nov 13 07:12:36 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 13 Nov 2002 09:12:36 +0200 (EET) Subject: [6bone] RFC2772 rewrite In-Reply-To: <5.1.0.14.0.20021112181333.0360f3e8@imap2.es.net> Message-ID: On Tue, 12 Nov 2002, Bob Fink wrote: > At 07:58 PM 11/12/2002 +0200, Pekka Savola wrote: > >On Tue, 12 Nov 2002, Bob Fink wrote: > > > Thus we would like to call for ideas/suggestions/issues for the rewrite. > > > Please send your comments to the list, or to one of the panel folk if you > > > want to comment privately. > > > > > > Also, if it would be useful to have an ad hoc 6bone meeting in Atlanta, > > > please let us know. Although I will not be at this IETF, someone else from > > > the panel could lead the discussion. > > > >Yes, I believe such a meeting could be useful. A more extensive > >discussion, possibly around problems/solutions in my draft (and other > >topics) would be possible -- there may be a little time allocated for this > >in the v6ops meeting, but I believe the time is probably a scarce resource > >there. > > We are not likely to allocate any v6ops time as it doesn't handle 6bone > stuff like ngtrans used to (but hasn't recently as we ran out of time). Note what the 6bone-mess _is_ within the charter of v6ops -- many of the different issues. It one of the most problematic "oparational deployment issues". But any longer 6bone-specific discussion is better kept in to a separate meeting. > I'll schedule a meeting in Atlanta. Thanks :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From fink@es.net Wed Nov 13 07:36:42 2002 From: fink@es.net (Bob Fink) Date: Tue, 12 Nov 2002 23:36:42 -0800 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon - correct date is 19 November Message-ID: <5.1.0.14.0.20021112233517.036401e0@imap2.es.net> 6bone Folk, By popular request ;-) there will be a 6bone meeting in Atlanta to discuss the RFC2772 rewrite. It will be held during the noon time break on Tuesday the 19th of November (not December... thanks to Michaek Warfield). To not conflict with room usage before and after, the meeting will convene at 11:45am and adjourn at 12.45pm. Rob Rockell will chair, and he will announce the meeting room to the list as soon as we can get the IETF Secretariat to assign the room, probably Monday the day before. Thanks, Bob From riel@conectiva.com.br Wed Nov 13 15:23:55 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Wed, 13 Nov 2002 13:23:55 -0200 (BRST) Subject: [6bone] RFC2772 rewrite In-Reply-To: <20021112175950.GA7250@bfib.colo.bit.nl> Message-ID: On Tue, 12 Nov 2002, Pim van Pelt wrote: > * Should we seperate the 6BONE cloud from the production IPv6 cloud ? This > is not really an RFC2772 issue, but does come to mind. > ... I have heard sounds of operators filtering out 3ffe::/16 due to its > impact on general availablility of IPv6 to their customers. This > deserves discussion! That doesn't make nearly as much sense as filtering out routes that come via 3ffe::/16 sites, or simply giving these routes a much lower preference so traffic always goes via production sites, if there is a route via production sites. I'm all for some kind of separation between the experimental and the production side of the ipv6 universe, especially if it means that I can keep ipv6 connectivity in the near future, when my ISP doesn't have ipv6 yet, but my own applications do rely on it. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Current spamtrap: october@surriel.com From paitken@cisco.com Wed Nov 13 15:32:57 2002 From: paitken@cisco.com (Paul Aitken) Date: Wed, 13 Nov 2002 15:32:57 +0000 Subject: [6bone] RFC2772 rewrite References: Message-ID: <3DD270A9.8050309@cisco.com> Rob, > If I don't hear anyone complain in 24 hours (good number to use) > we'll stick that in there :) *complain* While I appreciate the sentiment behind this suggestion, and wouldn't be surprised to find that most folks on the list meet the requirement, I'd expect that there are some folks who do actually have a life and actually do non work-related things at the weekend and I wouldn't want to discourage that in any way! Besides, there are plenty of other times when we're out of touch for more than 24 hours, during which time we expect our networks to run happily without our constant supervision, right? As Daniel said: > I don't think that 24hours is bad for a *response* - maybe not > resolution though. An autoresponder or ticketing system would meet the response requirement without actually dealing with the problem in any way :-( So what are we trying to achieve? To force the pTLA holder to respond, or to encourage them to resolve the technical issue? What would happen if it took 48 hours to respond to an issue - would the time police reject the holder's pTLA? Will someone volunteer to be "big brother" to ensure timely responses? Perhaps all we should ask is that "the applicant agrees to respond to technical problems in a timely fashion", and leave discernment to each case as appropriate? Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. From rrockell@sprint.net Wed Nov 13 15:43:40 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Wed, 13 Nov 2002 10:43:40 -0500 (EST) Subject: [6bone] RFC2772 rewrite In-Reply-To: <3DD270A9.8050309@cisco.com> Message-ID: How about something to the effect of: "pTLA holder should be responsive. Preferably, a response within 24 hours is appreciated. If a pTLA holder is non-responsive to repetitive requests for assistance, or does not resolve a problem in a timely fasion, the 6bone mailing serves as a great place to bring this issue to a greater audience. Should a pTLA continually remain unresponsive to issues surrounding the behavior of that pTLA, said pTLA holder may be subject to repremand, with the potential of revocation of that pTLA, based on concensus by " I'll not commment as to whether my weekend qualifies as 'having a life' or not, I do agree that 24 hours is a best effort practice... I've had our sysadmins BREAK my e-mail for more than 24 hours, if you can belive that... So 24 hours is a guideline, but not a 'move it or lose it' rule? Make sense? Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On Wed, 13 Nov 2002, Paul Aitken wrote: ->Rob, -> -> > If I don't hear anyone complain in 24 hours (good number to use) -> > we'll stick that in there :) -> ->*complain* -> ->While I appreciate the sentiment behind this suggestion, and wouldn't be ->surprised to find that most folks on the list meet the requirement, I'd ->expect that there are some folks who do actually have a life and ->actually do non work-related things at the weekend and I ->wouldn't want to discourage that in any way! -> ->Besides, there are plenty of other times when we're out of touch for ->more than 24 hours, during which time we expect our networks to run ->happily without our constant supervision, right? -> ->As Daniel said: -> -> > I don't think that 24hours is bad for a *response* - maybe not -> > resolution though. -> ->An autoresponder or ticketing system would meet the response requirement ->without actually dealing with the problem in any way :-( -> ->So what are we trying to achieve? To force the pTLA holder to respond, ->or to encourage them to resolve the technical issue? What would happen ->if it took 48 hours to respond to an issue - would the time police ->reject the holder's pTLA? Will someone volunteer to be "big brother" to ->ensure timely responses? -> ->Perhaps all we should ask is that "the applicant agrees to respond to ->technical problems in a timely fashion", and leave discernment to each ->case as appropriate? -> ->Cheers. ->-- ->Paul Aitken ->IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. -> From paitken@cisco.com Wed Nov 13 16:26:16 2002 From: paitken@cisco.com (Paul Aitken) Date: Wed, 13 Nov 2002 16:26:16 +0000 Subject: [6bone] RFC2772 rewrite References: Message-ID: <3DD27D28.1010109@cisco.com> Rob, > How about something to the effect of: > > [...] Yup, that pretty spells out the letter of the law! > I'll not commment as to whether my weekend qualifies as 'having a > life' or not :-( > I do agree that 24 hours is a best effort practice... I've had our > sysadmins BREAK my e-mail for more than 24 hours, if you can belive > that... Gosh, a whole 24 hours with not a single email? What joy! > So 24 hours is a guideline, but not a 'move it or lose it' rule? Sure! I much prefer encouragement over hard and fast rules :-) Cheers. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. From gert@space.net Wed Nov 13 16:28:14 2002 From: gert@space.net (Gert Doering) Date: Wed, 13 Nov 2002 17:28:14 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: ; from rrockell@sprint.net on Wed, Nov 13, 2002 at 10:43:40AM -0500 References: <3DD270A9.8050309@cisco.com> Message-ID: <20021113172814.P94537@Space.Net> Hi, On Wed, Nov 13, 2002 at 10:43:40AM -0500, Robert J. Rockell wrote: > How about something to the effect of: > > "pTLA holder should be responsive. Preferably, a response within 24 hours is > appreciated. If a pTLA holder is non-responsive to repetitive requests for > assistance, or does not resolve a problem in a timely fasion, the 6bone > mailing serves as a great place to bring this issue to a greater audience. > Should a pTLA continually remain unresponsive to issues surrounding the > behavior of that pTLA, said pTLA holder may be subject to repremand, with > the potential of revocation of that pTLA, based on concensus by steering group>" I like that version. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48540 (48282) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From nicolas.deffayet@ndsoftware.net Wed Nov 13 16:32:11 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 13 Nov 2002 17:32:11 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: References: Message-ID: <1037205132.665.1072.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-11-13 at 16:23, Rik van Riel wrote: > On Tue, 12 Nov 2002, Pim van Pelt wrote: > > > * Should we seperate the 6BONE cloud from the production IPv6 cloud ? This > > is not really an RFC2772 issue, but does come to mind. > > > ... I have heard sounds of operators filtering out 3ffe::/16 due to its > > impact on general availablility of IPv6 to their customers. This > > deserves discussion! http://www.noc.easynet.net/network/public/peering-ipv6.html --- Route Filtering We apply the following filters to announcements: Block Minimal prefixlength Maximal prefixlength 2001::/16 29 40 2002::/16 16 16 3FFE::/16 not announced --- What's the best ? - have a tunnel peer with a ISP who use production address - have a native peer with a ISP who use 6bone address I prefer have a native peer with a ISP who use 6bone address ! The address type (production or 6bone) should NOT be a peer criteria. Only allocation size (sTLA, pTLA, NLA) can be a peer criteria. You can have a bad peering with a peer who use production address and have a good peering with a peer who use 6bone address. > That doesn't make nearly as much sense as filtering out routes > that come via 3ffe::/16 sites, or simply giving these routes a > much lower preference so traffic always goes via production > sites, if there is a route via production sites. > > I'm all for some kind of separation between the experimental > and the production side of the ipv6 universe, especially if it > means that I can keep ipv6 connectivity in the near future, > when my ISP doesn't have ipv6 yet, but my own applications do > rely on it. What's a production site ? - a ISP who have RIR address (2001::/16) - a ISP who have native peering - a ISP who do commercial activities Many ISP who use production address (2001::/16) claim to do experimental stuff... Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From nicolas.deffayet@ndsoftware.net Wed Nov 13 16:44:28 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 13 Nov 2002 17:44:28 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: <3DD270A9.8050309@cisco.com> References: <3DD270A9.8050309@cisco.com> Message-ID: <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-11-13 at 16:32, Paul Aitken wrote: Paul, > > If I don't hear anyone complain in 24 hours (good number to use) > > we'll stick that in there :) > > *complain* > > While I appreciate the sentiment behind this suggestion, and wouldn't be > surprised to find that most folks on the list meet the requirement, I'd > expect that there are some folks who do actually have a life and > actually do non work-related things at the weekend and I > wouldn't want to discourage that in any way! >From RFC2772: 2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following: a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA applicant. A pTLA is managed by many people. If a network is correctly managed, there is always someone available for solve technical problems. > Besides, there are plenty of other times when we're out of touch for > more than 24 hours, during which time we expect our networks to run > happily without our constant supervision, right? > > As Daniel said: > > > I don't think that 24hours is bad for a *response* - maybe not > > resolution though. > > An autoresponder or ticketing system would meet the response requirement > without actually dealing with the problem in any way :-( > > So what are we trying to achieve? To force the pTLA holder to respond, > or to encourage them to resolve the technical issue? What would happen > if it took 48 hours to respond to an issue - would the time police > reject the holder's pTLA? Will someone volunteer to be "big brother" to > ensure timely responses? Autoresponder or ticketing system don't solve the problem of reply and the technical problem. Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From rrockell@sprint.net Wed Nov 13 16:56:31 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Wed, 13 Nov 2002 11:56:31 -0500 (EST) Subject: [6bone] RFC2772 rewrite In-Reply-To: <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> Message-ID: I would agree that sometimes, guaranteeing resolution in a timely manner is difficult. Learning curves aside, bugs in all forms of software, from end-system, to DNS, to Router, can provide for delay times in excess of 24 hours. this is permissible, so long as the pTLA can scope the problem to minimize impact on the global 6bone, right? Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On 13 Nov 2002, Nicolas DEFFAYET wrote: ->On Wed, 2002-11-13 at 16:32, Paul Aitken wrote: ->Paul, -> ->> > If I don't hear anyone complain in 24 hours (good number to use) ->> > we'll stick that in there :) ->> ->> *complain* ->> ->> While I appreciate the sentiment behind this suggestion, and wouldn't be ->> surprised to find that most folks on the list meet the requirement, I'd ->> expect that there are some folks who do actually have a life and ->> actually do non work-related things at the weekend and I ->> wouldn't want to discourage that in any way! -> ->>From RFC2772: -> -> 2. The pTLA Applicant MUST have the ability and intent to provide -> "production-quality" 6Bone backbone service. Applicants must -> provide a statement and information in support of this claim. -> This MUST include the following: -> -> -> a. A support staff of two persons minimum, three preferable, with -> person attributes registered for each in the ipv6-site object -> for the pTLA applicant. -> -> ->A pTLA is managed by many people. -> ->If a network is correctly managed, there is always someone available for ->solve technical problems. -> ->> Besides, there are plenty of other times when we're out of touch for ->> more than 24 hours, during which time we expect our networks to run ->> happily without our constant supervision, right? ->> ->> As Daniel said: ->> ->> > I don't think that 24hours is bad for a *response* - maybe not ->> > resolution though. ->> ->> An autoresponder or ticketing system would meet the response requirement ->> without actually dealing with the problem in any way :-( ->> ->> So what are we trying to achieve? To force the pTLA holder to respond, ->> or to encourage them to resolve the technical issue? What would happen ->> if it took 48 hours to respond to an issue - would the time police ->> reject the holder's pTLA? Will someone volunteer to be "big brother" to ->> ensure timely responses? -> ->Autoresponder or ticketing system don't solve the problem of reply and ->the technical problem. -> ->Best Regards, -> ->Nicolas DEFFAYET, NDSoftware ->NOC Website: http://noc.ndsoftwarenet.com/ ->FNIX6: http://www.fnix6.net/ -> From paitken@cisco.com Wed Nov 13 17:52:27 2002 From: paitken@cisco.com (Paul Aitken) Date: Wed, 13 Nov 2002 17:52:27 +0000 Subject: [6bone] RFC2772 rewrite References: <3DD270A9.8050309@cisco.com> <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <3DD2915B.3090102@cisco.com> Nicolas, > A pTLA is managed by many people. Allegedly, yes. > If a network is correctly managed, there is always someone available for > solve technical problems. Not so. Cisco doesn't require us to work 24 x 7, though we enjoy our work so much that we're often available out of hours - and I'm sure the same holds true for other pTLA's too. But I expect that many technical contacts from existing pTLA's will be out of touch while they travel to the IETF. Presumably if you take your girlfriend away for the weekend then either you persuade her to let you take your laptop computer with you, or you get Mike Cheney to stand in for you, right? > Autoresponder or ticketing system don't solve the problem of reply and > the technical problem. Yes, that was my point exactly - but they do meet the wording of your requirement of a response within 24 hours. Having 99.9...% of queries responded to in under a minute looks great as a statistic, but is totally useless unless there's human intervention to back it up. So best to ask for the human intervention rather than the response, eh? -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. From Robert.Kiessling@de.easynet.net Wed Nov 13 20:03:52 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 13 Nov 2002 20:03:52 +0000 Subject: [6bone] RFC2772 rewrite In-Reply-To: <3DD2915B.3090102@cisco.com> References: <3DD270A9.8050309@cisco.com> <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> <3DD2915B.3090102@cisco.com> Message-ID: Paul Aitken writes: > Presumably if you take your girlfriend away for the weekend then > either you persuade her to let you take your laptop computer with you, > or you get Mike Cheney to stand in for you, right? You have a very good point pointing to a serious conflict. You and others operate pTLAs and provide many valuable services to the community. However, it's operated as a spare-time activity without, for example, guaranteed response times. This leads to serious operational impact on the whole IPv6 world. I just want to recall the AS1654 incidence, where a hobby pTLA brought down significant parts of the global IPv6 network and we were lucky enough that the IPv4 upstream was available to turn off the tunnel endpoint. As a result the IPv6 network quality is considerably worse than IPv4, and understandably people are reluctant to trust important services to IPv6. I see only two solutions: 1. Isolate 6bone and similarly operated one-host-wildly-tunneled sTLAs from a production-quality IPv6 core, and widely implement filtering. 2. Assure that pTLAs provide a minimum of service. Robert From rrockell@sprint.net Wed Nov 13 20:26:37 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Wed, 13 Nov 2002 15:26:37 -0500 (EST) Subject: [6bone] RFC2772 rewrite In-Reply-To: Message-ID: I think we are going to write in someting specifying a 'minimum level of service'. However, quantifying that is going to be hard. I think the INTENT of the launguage will point to a robust support infrastructure, but as long as companies provide non-revenue-generating service, I don't think it is fair to assume a ISP-NOC like level of service. The goal is to get there, and we'll put verbiage in that allows for repurcussions if someone is providing what is commonly felt to be 'non-production-like' service. Will this satisfy all parties? Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On 13 Nov 2002, Robert Kiessling wrote: ->Paul Aitken writes: -> ->> Presumably if you take your girlfriend away for the weekend then ->> either you persuade her to let you take your laptop computer with you, ->> or you get Mike Cheney to stand in for you, right? -> ->You have a very good point pointing to a serious conflict. -> ->You and others operate pTLAs and provide many valuable services to the ->community. However, it's operated as a spare-time activity without, ->for example, guaranteed response times. -> ->This leads to serious operational impact on the whole IPv6 world. I ->just want to recall the AS1654 incidence, where a hobby pTLA brought ->down significant parts of the global IPv6 network and we were lucky ->enough that the IPv4 upstream was available to turn off the tunnel ->endpoint. -> ->As a result the IPv6 network quality is considerably worse than IPv4, ->and understandably people are reluctant to trust important services to ->IPv6. -> ->I see only two solutions: -> ->1. Isolate 6bone and similarly operated one-host-wildly-tunneled sTLAs ->from a production-quality IPv6 core, and widely implement filtering. -> ->2. Assure that pTLAs provide a minimum of service. -> ->Robert -> ->_______________________________________________ ->6bone mailing list ->6bone@mailman.isi.edu ->http://mailman.isi.edu/mailman/listinfo/6bone -> From andy@ipng.org.uk Wed Nov 13 20:38:36 2002 From: andy@ipng.org.uk (Andy Furnell) Date: Wed, 13 Nov 2002 20:38:36 +0000 Subject: [6bone] RFC2772 rewrite In-Reply-To: References: <3DD270A9.8050309@cisco.com> <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> <3DD2915B.3090102@cisco.com> Message-ID: <20021113203836.GC11288@penfold.noc.clara.net> On Wed, Nov 13, 2002 at 08:03:52PM +0000, Robert Kiessling wrote: > > Paul Aitken writes: > > > Presumably if you take your girlfriend away for the weekend then > > either you persuade her to let you take your laptop computer with you, > > or you get Mike Cheney to stand in for you, right? > > You have a very good point pointing to a serious conflict. > > You and others operate pTLAs and provide many valuable services to the > community. However, it's operated as a spare-time activity without, > for example, guaranteed response times. > > This leads to serious operational impact on the whole IPv6 world. I > just want to recall the AS1654 incidence, where a hobby pTLA brought > down significant parts of the global IPv6 network and we were lucky > enough that the IPv4 upstream was available to turn off the tunnel > endpoint. > > As a result the IPv6 network quality is considerably worse than IPv4, > and understandably people are reluctant to trust important services to > IPv6. > > I see only two solutions: > > 1. Isolate 6bone and similarly operated one-host-wildly-tunneled sTLAs > from a production-quality IPv6 core, and widely implement filtering. > > 2. Assure that pTLAs provide a minimum of service. > > Robert That's not to say that hobby ISPs can't have good response times though. Everyone has to start somewhere, and often it's not practical (predominantly for financial reasons :) to devote 100% of your time (and of your colleagues' time) to a project. Many IPv4 ISPs have been started as 'back bedroom' ISPs, and many small-medium providers are still run as such. I'd hate to see requirements appertaining to the necessity for 'full time staff', as in many cases this isn't possible. I think what's important is that staff are contactable 24/7, and that there will always be staff around to handle any network issues that may arise. At the moment the v6 project I'm a part of is only being run part time, and not for profit. That's not to say it's any less worthwhile than a full-blown commercial project (I'm finding increasingly that I'm spending an equal amount of time on my daytime paid job and my evenings unpaid job), but I can see where people could have a problem with this. While I'm always careful to ensure that there is always a point of contact for the v6 services, I do agree that unless a service has dedicated staff it can be difficult to devote time to fixing any problems that arise. Just because a project is only part-time for its staff doesn't mean that they can't guarantee a response time. I think the trick here is going to be to ensure that a minimum level of service can be achieved. How this is determined I have no idea, but I would be the first person to object if worthwhile projects were turned down the opportunity to take the first step towards being a full-blown enterprise because of a requirement that hadn't been fully thought out. Just my 2 cents :) A -- Andy Furnell andy@ipng.org.uk From nicolas.deffayet@ndsoftware.net Wed Nov 13 21:53:19 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 13 Nov 2002 22:53:19 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: References: <3DD270A9.8050309@cisco.com> <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> <3DD2915B.3090102@cisco.com> Message-ID: <1037224399.669.1573.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-11-13 at 21:03, Robert Kiessling wrote: > You and others operate pTLAs and provide many valuable services to the > community. However, it's operated as a spare-time activity without, > for example, guaranteed response times. > > This leads to serious operational impact on the whole IPv6 world. I > just want to recall the AS1654 incidence, where a hobby pTLA brought > down significant parts of the global IPv6 network and we were lucky > enough that the IPv4 upstream was available to turn off the tunnel > endpoint. The AS1654 incidence is not a 6bone specific problem. A production network can have the same (or similar) problem. Don't forget, BGP is not a secure protocol. > As a result the IPv6 network quality is considerably worse than IPv4, > and understandably people are reluctant to trust important services to > IPv6. > > I see only two solutions: > > 1. Isolate 6bone and similarly operated one-host-wildly-tunneled sTLAs > from a production-quality IPv6 core, and widely implement filtering. > > 2. Assure that pTLAs provide a minimum of service. I support your second solution. Best Regards, Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From andrew@2sheds.de Wed Nov 13 22:34:24 2002 From: andrew@2sheds.de (andrew@2sheds.de) Date: Wed, 13 Nov 2002 23:34:24 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: <20021113203836.GC11288@penfold.noc.clara.net> References: <3DD270A9.8050309@cisco.com> <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> <3DD2915B.3090102@cisco.com> <20021113203836.GC11288@penfold.noc.clara.net> Message-ID: <20021113223424.GA6845@ernie.2sheds.de> On Wed, Nov 13, 2002 at 08:38:36PM +0000, Andy Furnell wrote: > That's not to say that hobby ISPs can't have good response times though. > Everyone has to start somewhere, and often it's not practical > (predominantly for financial reasons :) to devote 100% of your time (and > of your colleagues' time) to a project. Many IPv4 ISPs have been started > as 'back bedroom' ISPs, and many small-medium providers are still run as > such. > There is a big difference here however... 'back bedroom' ISPs usually don't start with AS Numbers and have 5 upstreams, and innumerous peers (tunneled)... In IPv4 you started small. At this stage you really need to ask what you want/ expect from IPv6, and whether the 'commercial Internet' should transit over 6Bone networks. One of the nice things about 6Bone is that it is a 'testbed' for IPv6, where mistakes benifit the learning process..... Or do we want to turn it into a second 'Internet'...? My 2c Andrew PS: Is this still valid? http://www.ietf.org/html.charters/OLD/6bone-charter.html (Couldn't find a newer one). From gert@space.net Wed Nov 13 22:39:26 2002 From: gert@space.net (Gert Doering) Date: Wed, 13 Nov 2002 23:39:26 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: <1037224399.669.1573.camel@wks1.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Wed, Nov 13, 2002 at 10:53:19PM +0100 References: <3DD270A9.8050309@cisco.com> <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> <3DD2915B.3090102@cisco.com> <1037224399.669.1573.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021113233926.U94537@Space.Net> Hi, On Wed, Nov 13, 2002 at 10:53:19PM +0100, Nicolas DEFFAYET wrote: > The AS1654 incidence is not a 6bone specific problem. > A production network can have the same (or similar) problem. > > Don't forget, BGP is not a secure protocol. BGP with decent filtering, especially of downstreams, could have prevented this type of accidents. The way BGP is used right now in wide parts of the "IPv6 world", and unfortunately also in many cases in the IPv4 world (no filters, rely on "good behaviour" of the peer) is of course widely open to abuse and accidents. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48540 (48282) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Daniel Austin" Message-ID: <001101c28b6e$47303400$611c08d9@kewlio.net> I think that is a better description than the one i gave earlier. A provider may take a bit longer on occasion, but if a provider constantly has problems and doesnt resolve them within a reasonable amount of time - we should look at that. Of course "reasonable amount of time" could mean anything. I personally make sure that i reply to any serious ipv6 request or problem within 24 hours. If i'm not available for that period of time, there are other people who will deal with the request. I know that for many organisations this might not be possible as, of course, ipv6 makes them no money right now! But i think we're trying to say that a provider should be positive in its responses if they plan to supply ipv6 services in the future. With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. ----- Original Message ----- From: "Robert J. Rockell" To: "Paul Aitken" Cc: "6BONE List" <6bone@mailman.isi.edu> Sent: Wednesday, November 13, 2002 3:43 PM Subject: Re: [6bone] RFC2772 rewrite > How about something to the effect of: > > "pTLA holder should be responsive. Preferably, a response within 24 hours is > appreciated. If a pTLA holder is non-responsive to repetitive requests for > assistance, or does not resolve a problem in a timely fasion, the 6bone > mailing serves as a great place to bring this issue to a greater audience. > Should a pTLA continually remain unresponsive to issues surrounding the > behavior of that pTLA, said pTLA holder may be subject to repremand, with > the potential of revocation of that pTLA, based on concensus by steering group>" > > I'll not commment as to whether my weekend qualifies as 'having a life' or > not, I do agree that 24 hours is a best effort practice... I've had our > sysadmins BREAK my e-mail for more than 24 hours, if you can belive that... > > So 24 hours is a guideline, but not a 'move it or lose it' rule? > > Make sense? > > > Thanks > Rob Rockell > SprintLink > (+1) 703-689-6322 > ----------------------------------------------------------------------- > > On Wed, 13 Nov 2002, Paul Aitken wrote: > > ->Rob, > -> > -> > If I don't hear anyone complain in 24 hours (good number to use) > -> > we'll stick that in there :) > -> > ->*complain* > -> > ->While I appreciate the sentiment behind this suggestion, and wouldn't be > ->surprised to find that most folks on the list meet the requirement, I'd > ->expect that there are some folks who do actually have a life and > ->actually do non work-related things at the weekend and I > ->wouldn't want to discourage that in any way! > -> > ->Besides, there are plenty of other times when we're out of touch for > ->more than 24 hours, during which time we expect our networks to run > ->happily without our constant supervision, right? > -> > ->As Daniel said: > -> > -> > I don't think that 24hours is bad for a *response* - maybe not > -> > resolution though. > -> > ->An autoresponder or ticketing system would meet the response requirement > ->without actually dealing with the problem in any way :-( > -> > ->So what are we trying to achieve? To force the pTLA holder to respond, > ->or to encourage them to resolve the technical issue? What would happen > ->if it took 48 hours to respond to an issue - would the time police > ->reject the holder's pTLA? Will someone volunteer to be "big brother" to > ->ensure timely responses? > -> > ->Perhaps all we should ask is that "the applicant agrees to respond to > ->technical problems in a timely fashion", and leave discernment to each > ->case as appropriate? > -> > ->Cheers. > ->-- > ->Paul Aitken > ->IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. > -> > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From Daniel Austin" <3DD27D28.1010109@cisco.com> Message-ID: <001701c28b6e$807af380$611c08d9@kewlio.net> Hi Guys, ----- Original Message ----- From: "Paul Aitken" To: "Robert J. Rockell" Cc: "6BONE List" <6bone@mailman.isi.edu> Sent: Wednesday, November 13, 2002 4:26 PM Subject: Re: [6bone] RFC2772 rewrite > Rob, > > > How about something to the effect of: > > > > [...] > > Yup, that pretty spells out the letter of the law! > > > I'll not commment as to whether my weekend qualifies as 'having a > > life' or not > > :-( > > > I do agree that 24 hours is a best effort practice... I've had our > > sysadmins BREAK my e-mail for more than 24 hours, if you can belive > > that... > > Gosh, a whole 24 hours with not a single email? What joy! > > > So 24 hours is a guideline, but not a 'move it or lose it' rule? > > Sure! I much prefer encouragement over hard and fast rules :-) Encouragement is definately the way to go - perhaps even called steering? :) Setting defined rules is always hard and people will always find exceptions too. With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. > Cheers. > -- > Paul Aitken > IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From Daniel Austin" Message-ID: <001d01c28b6f$384e9520$611c08d9@kewlio.net> Hi Robert / other 6bone folk, ----- Original Message ----- From: "Robert J. Rockell" To: "Nicolas DEFFAYET" Cc: "Paul Aitken" ; "6BONE List" <6bone@mailman.isi.edu> Sent: Wednesday, November 13, 2002 4:56 PM Subject: Re: [6bone] RFC2772 rewrite > I would agree that sometimes, guaranteeing resolution in a timely manner is > difficult. Learning curves aside, bugs in all forms of software, from > end-system, to DNS, to Router, can provide for delay times in excess of 24 > hours. this is permissible, so long as the pTLA can scope the problem to > minimize impact on the global 6bone, right? A definitive resolution may take more than 24 hours, but as long as a provider is actively trying to fix a problem i think we are achieving what we want. Not all problems can be resolved in 24 hours and certainly not in a development environment. It doesnt take much to reply to an email with a couple of updates along the way :-) However, as per the earlier e-mails, everyone can get problems and in this kind of environment i think they're unavoidable. What we need to steer away from is "one man bands" making themselves appear larger than they are and then becoming overloaded with problems. I know we have the multiple contacts in the 6bone guidelines - but it's pretty simple to make a name and email address up! (in case anyone feels like checking mine - my other contact is a listed director of the company too!) It's fun to play a big company, but it hinders development on this level. With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. > Thanks > Rob Rockell > SprintLink > (+1) 703-689-6322 > ----------------------------------------------------------------------- > > On 13 Nov 2002, Nicolas DEFFAYET wrote: > > ->On Wed, 2002-11-13 at 16:32, Paul Aitken wrote: > ->Paul, > -> > ->> > If I don't hear anyone complain in 24 hours (good number to use) > ->> > we'll stick that in there :) > ->> > ->> *complain* > ->> > ->> While I appreciate the sentiment behind this suggestion, and wouldn't be > ->> surprised to find that most folks on the list meet the requirement, I'd > ->> expect that there are some folks who do actually have a life and > ->> actually do non work-related things at the weekend and I > ->> wouldn't want to discourage that in any way! > -> > ->>From RFC2772: > -> > -> 2. The pTLA Applicant MUST have the ability and intent to provide > -> "production-quality" 6Bone backbone service. Applicants must > -> provide a statement and information in support of this claim. > -> This MUST include the following: > -> > -> > -> a. A support staff of two persons minimum, three preferable, with > -> person attributes registered for each in the ipv6-site object > -> for the pTLA applicant. > -> > -> > ->A pTLA is managed by many people. > -> > ->If a network is correctly managed, there is always someone available for > ->solve technical problems. > -> > ->> Besides, there are plenty of other times when we're out of touch for > ->> more than 24 hours, during which time we expect our networks to run > ->> happily without our constant supervision, right? > ->> > ->> As Daniel said: > ->> > ->> > I don't think that 24hours is bad for a *response* - maybe not > ->> > resolution though. > ->> > ->> An autoresponder or ticketing system would meet the response requirement > ->> without actually dealing with the problem in any way :-( > ->> > ->> So what are we trying to achieve? To force the pTLA holder to respond, > ->> or to encourage them to resolve the technical issue? What would happen > ->> if it took 48 hours to respond to an issue - would the time police > ->> reject the holder's pTLA? Will someone volunteer to be "big brother" to > ->> ensure timely responses? > -> > ->Autoresponder or ticketing system don't solve the problem of reply and > ->the technical problem. > -> > ->Best Regards, > -> > ->Nicolas DEFFAYET, NDSoftware > ->NOC Website: http://noc.ndsoftwarenet.com/ > ->FNIX6: http://www.fnix6.net/ > -> > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From Daniel Austin" <3DD270A9.8050309@cisco.com> <1037205868.660.1097.camel@wks1.fr.corp.ndsoftware.com> <3DD2915B.3090102@cisco.com> Message-ID: <002301c28b70$01f003a0$611c08d9@kewlio.net> Hi Guys/Girls(?), ----- Original Message ----- From: "Paul Aitken" To: "Nicolas DEFFAYET" Cc: "Robert J. Rockell" ; "6BONE List" <6bone@mailman.isi.edu> Sent: Wednesday, November 13, 2002 5:52 PM Subject: Re: [6bone] RFC2772 rewrite > Nicolas, > > > A pTLA is managed by many people. > > Allegedly, yes. See my previous mail :P > > If a network is correctly managed, there is always someone available for > > solve technical problems. > > Not so. Cisco doesn't require us to work 24 x 7, though we enjoy our > work so much that we're often available out of hours - and I'm sure the > same holds true for other pTLA's too. But I expect that many technical > contacts from existing pTLA's will be out of touch while they travel to > the IETF. This is often the case (in UK companies at least) where time during the day is limited. (a good example is me sending this email at 11:50pm :P) As a non-profit making venture, i'd imagine a lot of companies are working out of hours for ipv6 - and we're glad of that! (Thanks to Paul for always responding to me in a timely manner - usually out of hours :P) > Presumably if you take your girlfriend away for the weekend then either > you persuade her to let you take your laptop computer with you, or you > get Mike Cheney to stand in for you, right? Or Chris Burton or Bruno Nash or Myriam Morel :P > > Autoresponder or ticketing system don't solve the problem of reply and > > the technical problem. > > Yes, that was my point exactly - but they do meet the wording of your > requirement of a response within 24 hours. Having 99.9...% of queries > responded to in under a minute looks great as a statistic, but is > totally useless unless there's human intervention to back it up. > > So best to ask for the human intervention rather than the response, eh? A human response is the best response. I really don't feel that i'm being helped if i get an auto-generated email telling me someone is looking into it. Now, if i get an email from a human - i feel much happier knowing that someone has actually read my email, understands it and recognises there is a problem. Sometimes this is half the problem in itself! Daniel. > -- > Paul Aitken > IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From Daniel Austin" Message-ID: <002b01c28b70$a03ac7c0$611c08d9@kewlio.net> ----- Original Message ----- From: "Robert J. Rockell" Sent: Wednesday, November 13, 2002 8:26 PM Subject: Re: [6bone] RFC2772 rewrite > I think we are going to write in someting specifying a 'minimum level of > service'. However, quantifying that is going to be hard. I think the > INTENT of the launguage will point to a robust support infrastructure, but > as long as companies provide non-revenue-generating service, I don't think > it is fair to assume a ISP-NOC like level of service. The goal is to get > there, and we'll put verbiage in that allows for repurcussions if someone is > providing what is commonly felt to be 'non-production-like' service. Will > this satisfy all parties? That seems fair to me. I feel that i should provide a good service to all people connected via IPv6 to us. I know the others that help me here also feel this way. If we want to seriously move to an ipv6 Internet, then we need to try our best to provide a production-like service (to the best extent of our non-revenue-generating activities!). If providers are repeatedly having massive problems, causing problems in the v6 routing tables or just being unresponsive then i think repurcussions are an acceptable way forward. With Thanks, Daniel Austin, Managing Director, kewlio.net Limited. > > > Thanks > Rob Rockell > SprintLink > (+1) 703-689-6322 > ----------------------------------------------------------------------- > > On 13 Nov 2002, Robert Kiessling wrote: > > ->Paul Aitken writes: > -> > ->> Presumably if you take your girlfriend away for the weekend then > ->> either you persuade her to let you take your laptop computer with you, > ->> or you get Mike Cheney to stand in for you, right? > -> > ->You have a very good point pointing to a serious conflict. > -> > ->You and others operate pTLAs and provide many valuable services to the > ->community. However, it's operated as a spare-time activity without, > ->for example, guaranteed response times. > -> > ->This leads to serious operational impact on the whole IPv6 world. I > ->just want to recall the AS1654 incidence, where a hobby pTLA brought > ->down significant parts of the global IPv6 network and we were lucky > ->enough that the IPv4 upstream was available to turn off the tunnel > ->endpoint. > -> > ->As a result the IPv6 network quality is considerably worse than IPv4, > ->and understandably people are reluctant to trust important services to > ->IPv6. > -> > ->I see only two solutions: > -> > ->1. Isolate 6bone and similarly operated one-host-wildly-tunneled sTLAs > ->from a production-quality IPv6 core, and widely implement filtering. > -> > ->2. Assure that pTLAs provide a minimum of service. > -> > ->Robert > -> > ->_______________________________________________ > ->6bone mailing list > ->6bone@mailman.isi.edu > ->http://mailman.isi.edu/mailman/listinfo/6bone > -> > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From mohacsi@niif.hu Thu Nov 14 08:00:51 2002 From: mohacsi@niif.hu (Janos Mohacsi) Date: Thu, 14 Nov 2002 09:00:51 +0100 (CET) Subject: [6bone] RFC2772 rewrite In-Reply-To: <1037205132.665.1072.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021114084519.P5664-100000@evil.ki.iif.hu> On Wed, 13 Nov 2002, Nicolas DEFFAYET wrote: > On Wed, 2002-11-13 at 16:23, Rik van Riel wrote: > > On Tue, 12 Nov 2002, Pim van Pelt wrote: > > > > > * Should we seperate the 6BONE cloud from the production IPv6 cloud ? This > > > is not really an RFC2772 issue, but does come to mind. > > > > > ... I have heard sounds of operators filtering out 3ffe::/16 due to its > > > impact on general availablility of IPv6 to their customers. This > > > deserves discussion! > > http://www.noc.easynet.net/network/public/peering-ipv6.html > > --- > Route Filtering > > We apply the following filters to announcements: > > Block Minimal prefixlength Maximal prefixlength > 2001::/16 29 40 > 2002::/16 16 16 > 3FFE::/16 not announced > --- > > > What's the best ? > > - have a tunnel peer with a ISP who use production address > - have a native peer with a ISP who use 6bone address Your examples are not the dividing points: Dividing point is, that you know (from your routing policy or the routing policy of your peering partners), that routes/prefixes you get is controlled in certain manner: 1. They can guarentee some kind of reachability (does not matter tunnel or peer). The tunnel reachability is much harder if you cannot control the IPv4 infrastructure... 2. The prefixes are aggregated accordingly. 3. You know how to control acceptance of the announced prefixes/routes. In one word you have a decent peering policy. > > I prefer have a native peer with a ISP who use 6bone address ! > > The address type (production or 6bone) should NOT be a peer criteria. > Only allocation size (sTLA, pTLA, NLA) can be a peer criteria. > > You can have a bad peering with a peer who use production address and > have a good peering with a peer who use 6bone address. > > > That doesn't make nearly as much sense as filtering out routes > > that come via 3ffe::/16 sites, or simply giving these routes a > > much lower preference so traffic always goes via production > > sites, if there is a route via production sites. > > > > I'm all for some kind of separation between the experimental > > and the production side of the ipv6 universe, especially if it > > means that I can keep ipv6 connectivity in the near future, > > when my ISP doesn't have ipv6 yet, but my own applications do > > rely on it. > > What's a production site ? > > - a ISP who have RIR address (2001::/16) > - a ISP who have native peering > - a ISP who do commercial activities > > Many ISP who use production address (2001::/16) claim to do experimental > stuff... See my comments above. Janos Mohacsi From rjorgensen@upctechnology.com Thu Nov 14 13:45:02 2002 From: rjorgensen@upctechnology.com (Roger Jorgensen) Date: Thu, 14 Nov 2002 14:45:02 +0100 Subject: [6bone] RFC2772 rewrite In-Reply-To: <20021112175950.GA7250@bfib.colo.bit.nl> References: <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> <5.1.0.14.0.20021112075834.03617fd8@imap2.es.net> Message-ID: <5.1.0.14.0.20021114144414.02be40c8@213.46.233.213> At 06:59 PM 11/12/2002 +0100, Pim van Pelt wrote: > >* Should we seperate the 6BONE cloud from the production IPv6 cloud ? This >is not really an RFC2772 issue, but does come to mind. It isn't really a RFC2772 issue but I guess but it's time to start thinking and have some more focus on all the routing issues we see in IPv6 space so we can make it a RFC2772 issue?:) About what Pim said, it's not a question about IF. I would say it's more a question on HOW. The reason for that statement are that there are people out there that simply don't trust the routing in the 6bone cloud. Are too many bad tunnels and insane tunnel connections out there. I've killed many tunnel/transit connection just because the connection are very bad. With time will we kill all tunnels to our ASN and run 100% native. With that move it would be logical to also consider, "how do we want to keep the connection to 6bone?" "do we want it?" About the routing mess issue, all connected parties to 6bone need to stop up and consider, "do we have good enough infrastructure to provide transit connectivity?" If you can't provide transit, sit down with your routing and start filtering. It's time to stop providing free transit to everyone and accept it from everyone, 6bone and the IPv6 Internet (yes I see them as two separate network actually) have grown too big and too complex for the free exchange of transit to work anymore... the ghost routes are one good example. Pekka's document, http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-01.txt are a good guide on the routing issue. Some experience I've had with IPv6 routing, guess I'm not the only one with it?? I wanted to reach a site I knew was in Europe. I got a route to it from EU, to US, then going around in US before it went back to EU and then finaly hit the target. Pingtime was stable 3-400ms...with decent filtering I probably could have reached the same site within 200ms. What is worse are that there are some ASN's out there that are "hijacking" routes, or that's how it feels like when you peer with that ASN. I can have two peering, one with AS1 (hijacking ASN and 100ms away) and one with AS2 (a 10ms tunnel), for some strange reason have I seen it again and again that the route are ALWAYS going over AS1. I've heard the same thing from others to so it's not only me that are seeing this. --- Roger Jorgensen (rjorgensen@upctechnology.com) System Engineer @ UPC Technology / IP engineering handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID From riel@conectiva.com.br Thu Nov 14 14:54:03 2002 From: riel@conectiva.com.br (Rik van Riel) Date: Thu, 14 Nov 2002 12:54:03 -0200 (BRST) Subject: [6bone] RFC2772 rewrite In-Reply-To: Message-ID: On 13 Nov 2002, Robert Kiessling wrote: > I see only two solutions: > > 1. Isolate 6bone and similarly operated one-host-wildly-tunneled sTLAs > from a production-quality IPv6 core, and widely implement filtering. > > 2. Assure that pTLAs provide a minimum of service. I vote for solution 1. Until ipv6 is widely available, there is a legitimate place for an experimental network (6bone) which is run by volunteers that simply don't have the resources to look after their pTLA 24x7. Making the requirements too strict will just cut off part of the current ipv6 userbase, probably even without achieving the stated goal because there will always be sites that operate within the "letter of the law", but still cause trouble... regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: october@surriel.com From rrockell@sprint.net Thu Nov 14 15:37:45 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Thu, 14 Nov 2002 10:37:45 -0500 (EST) Subject: [6bone] RFC2772 rewrite In-Reply-To: Message-ID: Perhaps we can allow for the 'volunteer' networks to exist, but not as pTLA's... Many of the volunteers do provide valuable services and testing cycles for ipv6. However, reliability in the core (even of the 6bone) will be somewhat necessary for any Volunteer organizations to talk to each other over IPv6... Inter-domain routing seems to be one of the largest issues surrounding Ipv6 deployment now.. We should keep that tight (or at least in as near a steady-state as possible) so researchers and others have the ability to test with the confidence that some factors remain static... rjr Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On Thu, 14 Nov 2002, Rik van Riel wrote: ->On 13 Nov 2002, Robert Kiessling wrote: -> ->> I see only two solutions: ->> ->> 1. Isolate 6bone and similarly operated one-host-wildly-tunneled sTLAs ->> from a production-quality IPv6 core, and widely implement filtering. ->> ->> 2. Assure that pTLAs provide a minimum of service. -> ->I vote for solution 1. Until ipv6 is widely available, there is ->a legitimate place for an experimental network (6bone) which is ->run by volunteers that simply don't have the resources to look ->after their pTLA 24x7. -> ->Making the requirements too strict will just cut off part of the ->current ipv6 userbase, probably even without achieving the stated ->goal because there will always be sites that operate within the ->"letter of the law", but still cause trouble... -> ->regards, -> ->Rik ->-- ->Bravely reimplemented by the knights who say "NIH". ->http://www.surriel.com/ http://guru.conectiva.com/ ->Current spamtrap: october@surriel.com -> ->_______________________________________________ ->6bone mailing list ->6bone@mailman.isi.edu ->http://mailman.isi.edu/mailman/listinfo/6bone -> From michel@arneill-py.sacramento.ca.us Thu Nov 14 16:24:46 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 14 Nov 2002 08:24:46 -0800 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon Message-ID: <2B81403386729140A3A899A8B39B046405E466@server2000> 6boner / Bob / Rob, At IETF-53 in Minneaopolis I presented a short thought-triggering doc, that we did not have time to debate. Although it could be refreshed, it appears to me completely in line as part of the thinking process of rewriting RFC 2772. Bob and/or Rob, please consider my request for a 15-minute slot, that would include discussion, and I promise I'll go faster than last time presenting ;-) The doc is here: http://arneill-py.sacramento.ca.us/ipv6mh/ietf53.ppt Michel. From fink@es.net Thu Nov 14 17:03:01 2002 From: fink@es.net (Bob Fink) Date: Thu, 14 Nov 2002 09:03:01 -0800 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon In-Reply-To: <2B81403386729140A3A899A8B39B046405E466@server2000> Message-ID: <5.1.0.14.0.20021114090151.03651d18@imap2.es.net> Michel, At 08:24 AM 11/14/2002 -0800, Michel Py wrote: >6boner / Bob / Rob, > >At IETF-53 in Minneaopolis I presented a short thought-triggering doc, >that we did not have time to debate. Although it could be refreshed, it >appears to me completely in line as part of the thinking process of >rewriting RFC 2772. > >Bob and/or Rob, please consider my request for a 15-minute slot, that >would include discussion, and I promise I'll go faster than last time >presenting ;-) As long as you go after the planned 2772 main topic. There are only 60 minutes in these lunchtime sessions. Also, if other folk want to present you may have to reduce to 10 mins. Thanks, Bob >The doc is here: >http://arneill-py.sacramento.ca.us/ipv6mh/ietf53.ppt > >Michel. > >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone From michel@arneill-py.sacramento.ca.us Thu Nov 14 18:15:18 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 14 Nov 2002 10:15:18 -0800 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon Message-ID: <2B81403386729140A3A899A8B39B046405E469@server2000> Bob / Rob / Pekka, >> Michel Py wrote: >> Bob and/or Rob, please consider my request for a 15-minute >> slot, that would include discussion, and I promise I'll go >> faster than last time presenting ;-) > Bob Fink wrote: > As long as you go after the planned 2772 main topic. There > are only 60 minutes in these lunchtime sessions. This is my goal. Unrelated to this: A little earlier, I suggested that part of the 2772 refresh could be devoted to incorporate some of the changes necessary to the move towards the RIRs. I have not heard feedback about this, do you think it's a good idea? Will Rob present something related to this? > Also, if other folk want to present you may have to reduce > to 10 mins. Fair. Pekka S., will you be presenting your draft? I so, I would suggest you present before I do. Thanks Michel From pekkas@netcore.fi Thu Nov 14 18:18:59 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 14 Nov 2002 20:18:59 +0200 (EET) Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon In-Reply-To: <2B81403386729140A3A899A8B39B046405E466@server2000> Message-ID: On Thu, 14 Nov 2002, Michel Py wrote: > At IETF-53 in Minneaopolis I presented a short thought-triggering doc, > that we did not have time to debate. Although it could be refreshed, it > appears to me completely in line as part of the thinking process of > rewriting RFC 2772. > > Bob and/or Rob, please consider my request for a 15-minute slot, that > would include discussion, and I promise I'll go faster than last time > presenting ;-) > > The doc is here: > http://arneill-py.sacramento.ca.us/ipv6mh/ietf53.ppt There's too much (in this context) irrelevant semantics, degrading the possible usefulness of this presentation. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From michel@arneill-py.sacramento.ca.us Thu Nov 14 18:22:16 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 14 Nov 2002 10:22:16 -0800 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon Message-ID: <2B81403386729140A3A899A8B39B04640BD37D@server2000> > There's too much (in this context) irrelevant semantics, > degrading the possible usefulness of this presentation. I agree, it needs to be refreshed. Keep in mind, this is the Minneapolis presentation, not the future one. Michel. From pekkas@netcore.fi Thu Nov 14 20:03:24 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 14 Nov 2002 22:03:24 +0200 (EET) Subject: [6bone] RFC2772 rewrite -- bigger scope goals Message-ID: Hello, First, before we try to modify RFC2772, I think we need to have an idea what we're trying to do: - policy for new allocations and for new organizations only? - policy for new and old pTLA holders alike (any policy we agree on MUST also by implemented by current pTLA's, as an item they agreed to in RFC2772)? Follow-up questions: is there a need for the policies for the old and the new be the same (IMO not necessarily)? What if don't conform to the new rules, the revocation process? The next question would be whether we want to keep 6bone de-facto free and open, and a "big mess", or try to do something about it. Views differ on this one; the options are basically (I hope I didn't miss any): 1) keep 6bone routing as it is, build totally separate competing v6 Internet for "production" 2) try to move 6bone-style routing off to the edges of the network a) try to clean up the current mess, or b) prevent any further mess in new-pTLA rules 3) kill 6bone Only after there's some rough consensus on these, we can proceed to the details in how to really revise RFC2772. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Robert.Kiessling@de.easynet.net Thu Nov 14 21:36:18 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 14 Nov 2002 21:36:18 +0000 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: References: Message-ID: Pekka Savola writes: > 3) kill 6bone Surely this will result in much flaming. Maybe it would help to first think about the concrete effects this would have. 1. Which current services are provided in 3FFE space which cannot feasibly move to RIR space? 2. Apart from services provided to the public, which other effects would it have to put a timeout on current allocations? 3. Which future developments are hindered if 6bone allocations were not available? Or more generally: What are 6bones goals today? Do we still need a "testbed to assist in the evolution and deployment of IPv6?" I would argue that "deployment" in the sense of "provide address space to use IPv6" should no longer be considered part of 6bone's mission. RIRs now provide this part. Practically 6bone is in direct competition with RIRs here, providing a different set of criteria, essentially: - RIR: LIR fees & 200 potential customers - 6bone: wait 6 months So what is the concrete benefit of having this cost-free alternative to RIR allocations? Robert From m.gargani@edisontel.it Thu Nov 14 22:30:37 2002 From: m.gargani@edisontel.it (Max Gargani) Date: 14 Nov 2002 23:30:37 +0100 Subject: [6bone] resolv problem Message-ID: <1037313038.2432.70.camel@work> Hi all, maybe this is not the right place or maybe I wrong something but since RIPE NCC gave to my company the reverse delegation for the allocated /32 ip6.arpa, all protocols such ssh, ircd etc etc, can't resolve the addresses. >From named log I see ssh & co ask to resolve i.p.v.6.a.d.d.r.e.s.s.ip6.int but all RIRs allocations are ip6.arpa. Anyone with same problem? Thanks, Max From ck@arch.bellsouth.net Fri Nov 15 00:31:28 2002 From: ck@arch.bellsouth.net (Christian Kuhtz) Date: Thu, 14 Nov 2002 19:31:28 -0500 Subject: [6bone] ipv6 on c827 Message-ID: <20021114193128.C9841@ns1.arch.bellsouth.net> hey gang, if there's anybody else 6bone'ing with a c827, please get in touch with me ;).. thanks, christian From jeroen@unfix.org Fri Nov 15 01:22:30 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 15 Nov 2002 02:22:30 +0100 Subject: [6bone] resolv problem In-Reply-To: <1037313038.2432.70.camel@work> Message-ID: <000d01c28c45$7890e8f0$210d640a@unfix.org> Max Gargani wrote: > Hi all, > > maybe this is not the right place or maybe I wrong something but since > RIPE NCC gave to my company the reverse delegation for the > allocated /32 ip6.arpa, all protocols such ssh, ircd etc etc, can't resolve the > addresses. > > From named log I see ssh & co ask to resolve > i.p.v.6.a.d.d.r.e.s.s.ip6.int but all RIRs allocations are ip6.arpa. You might start updating your resolver libraries to use ip6.arpa which now the defacto standard. Notez bien that only 6bone space (3ffe::/16) isn't delegated to ip6.arpa (yet). But that will likely be happing really soon now after some political issues are burried. Most _current_ resolver libraries will currently try: ip6.arpa. ip6.int. The second one only when the first one fails ofcourse. Thus you should at least make reverse entries in ip6.arpa and you could add ip6.int entries. Ask RIPE NCC to delegate either of them to your dnsservers if you want so. Greets, Jeroen From fink@es.net Fri Nov 15 02:31:52 2002 From: fink@es.net (Bob Fink) Date: Thu, 14 Nov 2002 18:31:52 -0800 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon In-Reply-To: <2B81403386729140A3A899A8B39B046405E469@server2000> Message-ID: <5.1.0.14.0.20021114180321.03696e10@imap2.es.net> At 10:15 AM 11/14/2002 -0800, Michel Py wrote: >Bob / Rob / Pekka, > > >> Michel Py wrote: > >> Bob and/or Rob, please consider my request for a 15-minute > >> slot, that would include discussion, and I promise I'll go > >> faster than last time presenting ;-) > > > Bob Fink wrote: > > As long as you go after the planned 2772 main topic. There > > are only 60 minutes in these lunchtime sessions. > >This is my goal. > >Unrelated to this: >A little earlier, I suggested that part of the 2772 refresh could be >devoted to incorporate some of the changes necessary to the move towards >the RIRs. I have not heard feedback about this, do you think it's a good >idea? Will Rob present something related to this? It all depends on how the RIR discussions progress. At this point it's not obvious to me we are ready to say anything as there still seems to be lots of concerns in the RIR community about doing this. So, nothing will get said on this at the 6bone meeting in Atlanta. If by the time we do the actual 2772 rewrite (as opposed to just discussing it as we are doing now) there is something useful to say, we will. Thanks, Bob From rrockell@sprint.net Fri Nov 15 02:41:57 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Thu, 14 Nov 2002 21:41:57 -0500 (EST) Subject: [6bone] new 2772 rewrite Message-ID: First attempt an 2772 rewrite is available at: http://www.6bone.net/misc/draft-ietf-rockell-6bone-ops-guide-00.txt Please take a peek at it, and send comments to me/the list/bring them to IETF. Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- From fink@es.net Fri Nov 15 02:42:58 2002 From: fink@es.net (Bob Fink) Date: Thu, 14 Nov 2002 18:42:58 -0800 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: Message-ID: <5.1.0.14.0.20021114181057.036896d8@imap2.es.net> Pekka, At 10:03 PM 11/14/2002 +0200, Pekka Savola wrote: >Hello, > >First, before we try to modify RFC2772, I think we need to have an idea >what we're trying to do: I totally agree. That's why I called for ideas/issues etc. When I don't see any comments on the list, however, I wonder if anyone cares (I do know that you and some others do). I would like to see an open and vigorous debate/discussion on what the 6bone's role should become in the next phase of a transition to v6. > - policy for new allocations and for new organizations only? > - policy for new and old pTLA holders alike (any policy we agree on MUST >also by implemented by current pTLA's, as an item they agreed to in >RFC2772)? I would think the latter. We have been skirting the issue of making existing pTLA holders clean up or change for several years. I believe it is time to get fairly specific. >Follow-up questions: is there a need for the policies for the old and the >new be the same (IMO not necessarily)? What if don't conform to the new >rules, the revocation process? We would need to address this. Peer group pressure, if there is a real consensus, can be quite powerful, meaning we can yank prefixes. >The next question would be whether we want to keep 6bone de-facto free and >open, and a "big mess", or try to do something about it. Views differ on >this one; the options are basically (I hope I didn't miss any): > 1) keep 6bone routing as it is, build totally separate competing v6 >Internet for "production" > 2) try to move 6bone-style routing off to the edges of the network > a) try to clean up the current mess, or > b) prevent any further mess in new-pTLA rules > 3) kill 6bone The 6bone will be killed sooner or later. It's primarily a question of how articulate we are in making the case for a longer than a shorter life (which includes real plans, not just talk). However, sometime in the next 1-5 years the 6bone prefix will get yanked. Let's use whatever the time to useful purposes. So, we need to have a good discussion on just the issues you raise. >Only after there's some rough consensus on these, we can proceed to the >details in how to really revise RFC2772. Agree, but, absent any other discussion, we will publish something to address what Rob and others think need be done. So let's have a wide ranging discussion in Atlanta on what is really best to do with the 6bone. Thanks, Bob From fink@es.net Fri Nov 15 03:04:23 2002 From: fink@es.net (Bob Fink) Date: Thu, 14 Nov 2002 19:04:23 -0800 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: References: Message-ID: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> Robert, At 09:36 PM 11/14/2002 +0000, Robert Kiessling wrote: >Pekka Savola writes: > > > 3) kill 6bone > >Surely this will result in much flaming. Maybe it would help to first >think about the concrete effects this would have. > >1. Which current services are provided in 3FFE space which cannot > feasibly move to RIR space? > >2. Apart from services provided to the public, which other effects > would it have to put a timeout on current allocations? > >3. Which future developments are hindered if 6bone allocations were > not available? > >Or more generally: > >What are 6bones goals today? > >Do we still need a "testbed to assist in the evolution and deployment >of IPv6?" > >I would argue that "deployment" in the sense of "provide address space >to use IPv6" should no longer be considered part of 6bone's mission. >RIRs now provide this part. Practically 6bone is in direct competition >with RIRs here, providing a different set of criteria, essentially: > >- RIR: LIR fees & 200 potential customers >- 6bone: wait 6 months > >So what is the concrete benefit of having this cost-free alternative >to RIR allocations? Primarily for sites and networks that want to try out v6, yet cannot allocate money for production service. We are not in production with v6 today in most parts of the world, by which I mean production code that just works using v6 without special effort. I would say that we are seeing this scenario, i.e., near cost-free trials of v6, more than any other. Thanks, Bob From michel@arneill-py.sacramento.ca.us Fri Nov 15 03:53:18 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 14 Nov 2002 19:53:18 -0800 Subject: [6bone] 6bone meeting in Atlanta, Tuesday noon Message-ID: <2B81403386729140A3A899A8B39B04640BD38C@server2000> > Bob Fink wrote: > So, nothing will get said on this at the 6bone meeting > in Atlanta. If by the time we do the actual 2772 rewrite > (as opposed to just discussing it as we are doing now) > there is something useful to say, we will. Willco. Michel. From jch@oleane.net Fri Nov 15 06:21:26 2002 From: jch@oleane.net (Jean-Claude Christophe) Date: Fri, 15 Nov 2002 07:21:26 +0100 Subject: [6bone] ipv6 on c827 In-Reply-To: <20021114193128.C9841@ns1.arch.bellsouth.net> References: <20021114193128.C9841@ns1.arch.bellsouth.net> Message-ID: <20021115062126.GP13765@oleane.net> hey Christian, There are no IPv6 support for the 820 series yet. Regards, According to Christian Kuhtz : > hey gang, > > if there's anybody else 6bone'ing with a c827, please get in touch > with me ;).. > > thanks, > christian > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone -- Jean-Claude Christophe / jch@oleane.net From ck@arch.bellsouth.net Fri Nov 15 06:50:41 2002 From: ck@arch.bellsouth.net (Christian Kuhtz) Date: Fri, 15 Nov 2002 01:50:41 -0500 Subject: fwd: [6bone] ipv6 on c827 Message-ID: <20021115015041.C14825@ns1.arch.bellsouth.net> i should probably send this to the list, since others might be interested in this as well... didn't realize the list had been copied on the original message to me. for those who care, the bug id i'm concerned about is CSCdw67009 or http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdw67009 except that it actually has nothing to do with ipsec as indicated in the bug description (in my case i'm using a 3des image, but there's no ipsec config'ed anywhere). bottom line, c827 w/ ipv6 unicast works. thanks, christian jean-claude, i'm sorry, but in fact you're wrong ;).. i'm running 12.2(8)T5 on an c827 just fine with unitcast & mcast ipv6, and ipv6 unicast. that is, except for a nasty bug causing crashes (unrelated to ipv6). was hoping to find other people doing the same and seeing what older ios versions might work. other than that, ipv6 on c827's works wonderfully. From pekkas@netcore.fi Fri Nov 15 06:50:23 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 15 Nov 2002 08:50:23 +0200 (EET) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <5.1.0.14.0.20021114181057.036896d8@imap2.es.net> Message-ID: On Thu, 14 Nov 2002, Bob Fink wrote: > At 10:03 PM 11/14/2002 +0200, Pekka Savola wrote: > >Hello, > > > >First, before we try to modify RFC2772, I think we need to have an idea > >what we're trying to do: > > I totally agree. That's why I called for ideas/issues etc. When I don't see > any comments on the list, however, I wonder if anyone cares (I do know that > you and some others do). > > I would like to see an open and vigorous debate/discussion on what the > 6bone's role should become in the next phase of a transition to v6. Exactly. We could just revise 2772 to be up-to-date, but I'm not sure if that's useful if we don't take into the account how we feel 6bone is going to change in the coming years. > > - policy for new allocations and for new organizations only? > > - policy for new and old pTLA holders alike (any policy we agree on MUST > >also by implemented by current pTLA's, as an item they agreed to in > >RFC2772)? > > I would think the latter. We have been skirting the issue of making > existing pTLA holders clean up or change for several years. I believe it is > time to get fairly specific. Agreed. > >Follow-up questions: is there a need for the policies for the old and the > >new be the same (IMO not necessarily)? What if don't conform to the new > >rules, the revocation process? > > We would need to address this. Peer group pressure, if there is a real > consensus, can be quite powerful, meaning we can yank prefixes. Yes. I believe there will have to be more text on the "non-conforming" case. For example, in the suggested text: --8<-- 3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest. Applicant must provide a statement and information in support this claim. WOOP; proposed replacement for #3. 3. The pTLA Applicant MUST intend fo provide ISP-like services that woudl be served by its becoming a pTLA. e.g., the Applicant is a major provider of Internet service in a region. Applicant must provider a statement and information in support of this claim. --8<-- ==> would we try to get rid of pTLA's from systems which do not fulfill the criteria for #3 (it's much more strict I think -- good), or do something else? This could be both a good thing and bad thing? ==> the similar (but to a lesser extent) applies to operators not implementing the new policy, due to many reasons (e.g. not even being or reading the 6bone mailing list!). > >Only after there's some rough consensus on these, we can proceed to the > >details in how to really revise RFC2772. > > Agree, but, absent any other discussion, we will publish something to > address what Rob and others think need be done. > > So let's have a wide ranging discussion in Atlanta on what is really best > to do with the 6bone. Agreed. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas@netcore.fi Fri Nov 15 07:03:42 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 15 Nov 2002 09:03:42 +0200 (EET) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: Message-ID: On 14 Nov 2002, Robert Kiessling wrote: > Pekka Savola writes: > > > 3) kill 6bone > > Surely this will result in much flaming. Maybe it would help to first > think about the concrete effects this would have. > > 1. Which current services are provided in 3FFE space which cannot > feasibly move to RIR space? Services, e.g. addressing, tunnels, free transit etc., provided for non-customers for free. Some do not want to move these to their RIR space -- I believe that's okay. > 2. Apart from services provided to the public, which other effects > would it have to put a timeout on current allocations? > > 3. Which future developments are hindered if 6bone allocations were > not available? The RIR policy has gotten much more flexible lately, so 6bone is no longer needed that much even for experimenting. Basically, it seems to me that new 6bone allocations seem to be non-LIR's, ie. not allowed to have RIR space anyway (anyone can think of exceptions??) -- we don't really want to give these a pTLA. Perhaps also some smaller ISP's which may be LIR's (but some are not) but do not fulfill the letter of 200 /48 allocations in the RIR space. So it seems to me that (all that many) further allocations shouldn't be even necessary, the question would mostly be on how to manage the current ones. > What are 6bones goals today? > > Do we still need a "testbed to assist in the evolution and deployment > of IPv6?" I'm not sure if this is necessary. > I would argue that "deployment" in the sense of "provide address space > to use IPv6" should no longer be considered part of 6bone's mission. > RIRs now provide this part. Practically 6bone is in direct competition > with RIRs here, providing a different set of criteria, essentially: > > - RIR: LIR fees & 200 potential customers > - 6bone: wait 6 months > > So what is the concrete benefit of having this cost-free alternative > to RIR allocations? 6bone address pTLA allocations, for new allocs, seem to be useful mostly to those that should not get it, and those which are small enough not to be able to get it through RIR's. (A relative fringe case are those who do have RIR space but want to offer services like tunnels to outsiders also.) But I believe the 6bone community _could_ _possibly_ be served by these slightly smaller ISP's getting 6bone space but not RIR space. The question is how to wordsmith the rules so that too small ones can't get it (e.g. one requirement could be AS number of your _own_, not loaned). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas@netcore.fi Fri Nov 15 15:22:54 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Fri, 15 Nov 2002 17:22:54 +0200 (EET) Subject: [6bone] Re: Designing IPv6 network guidelines? In-Reply-To: Message-ID: On Wed, 28 Feb 2001, Hareesh V H wrote: > hi! the discussion about the network designing in IPv6 is a very relevant > one. Actually i am trying to produce a document in this regard. One point > i find interesting is the ambiguity in the specification/implementation of > site local addresses. The implementations as of now or even the specs > do not give a very clear idea about it. Could anyone please provide more > info/links about this issue as to how exactly this feature is to be used? > Thanks in advance. Please don't use site-local addresses if you have permanent connection to the Internet. For other purposes, the usability is debatable (and indeed, it has been under heavy debate in the IPv6 wg mailing list lately). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From bmanning@ISI.EDU Fri Nov 15 17:10:32 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 15 Nov 2002 09:10:32 -0800 (PST) Subject: [6bone] resolv problem In-Reply-To: <000d01c28c45$7890e8f0$210d640a@unfix.org> from Jeroen Massar at "Nov 15, 2 02:22:30 am" Message-ID: <200211151710.gAFHAXN21959@boreas.isi.edu> unless/until 3ffe::/16 is in the ip6.arpa tree, you can get it under the ip6.int tree by sending email to hostmaster@ep.net with the delegation and the associated nameservers. If its an RIR delegation, you must use their dns registration processes. % Max Gargani wrote: % % > Hi all, % > % > maybe this is not the right place or maybe I wrong something but since % > RIPE NCC gave to my company the reverse delegation for the % > allocated /32 ip6.arpa, all protocols such ssh, ircd etc etc, can't % resolve the % > addresses. % > % > From named log I see ssh & co ask to resolve % > i.p.v.6.a.d.d.r.e.s.s.ip6.int but all RIRs allocations are ip6.arpa. % % You might start updating your resolver libraries to use ip6.arpa which % now the defacto standard. % Notez bien that only 6bone space (3ffe::/16) isn't delegated to ip6.arpa % (yet). % But that will likely be happing really soon now after some political % issues are burried. % % Most _current_ resolver libraries will currently try: % ip6.arpa. % ip6.int. % The second one only when the first one fails ofcourse. % % Thus you should at least make reverse entries in ip6.arpa and you could % add ip6.int entries. % Ask RIPE NCC to delegate either of them to your dnsservers if you want % so. % % Greets, % Jeroen % % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone % -- --bill From rrockell@sprint.net Fri Nov 15 17:25:23 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Fri, 15 Nov 2002 12:25:23 -0500 (EST) Subject: [6bone] Re: new 2772 rewrite In-Reply-To: Message-ID: I don't know if this ever arrived to the mailing list, so I'm reposting. Ignore if this is a mistake. Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On Thu, 14 Nov 2002, Robert J. Rockell wrote: ->First attempt an 2772 rewrite is available at: -> ->http://www.6bone.net/misc/draft-ietf-rockell-6bone-ops-guide-00.txt -> ->Please take a peek at it, and send comments to me/the list/bring them to ->IETF. -> ->Thanks ->Rob Rockell ->SprintLink ->(+1) 703-689-6322 ->----------------------------------------------------------------------- -> -> From nicolas.deffayet@ndsoftware.net Fri Nov 15 18:14:33 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 15 Nov 2002 19:14:33 +0100 Subject: [6bone] Re: new 2772 rewrite In-Reply-To: References: Message-ID: <1037384073.633.856.camel@wks1.fr.corp.ndsoftware.com> On Fri, 2002-11-15 at 18:25, Robert J. Rockell wrote: > I don't know if this ever arrived to the mailing list, so I'm reposting. > Ignore if this is a mistake. > > On Thu, 14 Nov 2002, Robert J. Rockell wrote: > > ->First attempt an 2772 rewrite is available at: > -> > ->http://www.6bone.net/misc/draft-ietf-rockell-6bone-ops-guide-00.txt > -> I get a 404 error :( -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From ehofmann@uu.net Fri Nov 15 21:36:51 2002 From: ehofmann@uu.net (Enno Hofmann) Date: Fri, 15 Nov 2002 22:36:51 +0100 Subject: [6bone] Re: resolv problem References: <200211151820.gAFIK2D03124@gamma.isi.edu> Message-ID: <3DD568F3.5080606@uu.net> Hi Max, Max Gargani wrote: > Hi all, > > maybe this is not the right place or maybe I wrong something but since > RIPE NCC gave to my company the reverse delegation for the allocated /32 > ip6.arpa, all protocols such ssh, ircd etc etc, can't resolve the > addresses. > > From named log I see ssh & co ask to resolve > i.p.v.6.a.d.d.r.e.s.s.ip6.int but all RIRs allocations are ip6.arpa. RIPE NCC can also delegate the ip6.int zone to you. ip6.int contains both, 6bone and RIR space, ip6.arpa currently _only_ contains RIR space. Just create the necessary objects in the RIPE-database, set up your nameserver and send a mail to RIPE as described at http://www.ripe.net/reverse/ipv6.html best regards, Enno Hofmann From rrockell@sprint.net Fri Nov 15 22:36:02 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Fri, 15 Nov 2002 17:36:02 -0500 (EST) Subject: [6bone] Meeting agenda in Atlanta Message-ID: So we will meet over lunch on Tuesday, at a room to be decided when I arrive and ask the IETF organizers which one I can use. Given the possibility of a projector that works, I propose the following agenda. Please add/edit as you see fit to the list. -Intro: (5 minutes) -6bone-Mess draft discussion (Pekka Savola)(10-15 minutes) -discussion (5-10 minutes) -2772bis changes (Rob Rockell) (10 minutes) -discussion (5-10 minutes) -What pieces of these two documents should be merged (5 minutes) -Michel presents thoughts on state of 6bone (10 minutes) referenced drafts for your pre-reading: 6bone-Mess: http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-01.txt 2772 re-write: http://www.6bone.net/misc/draft-ietf-rockell-6bone-ops-guide-00.txt Note: 2772 re-write may be Ipv4 accessible only (not my server, complaints to admin of www.6bone.net :) ). Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- From m.gargani@edisontel.it Fri Nov 15 22:42:57 2002 From: m.gargani@edisontel.it (Max Gargani) Date: 15 Nov 2002 23:42:57 +0100 Subject: [6bone] resolv problem In-Reply-To: <1037313038.2432.70.camel@work> References: <1037313038.2432.70.camel@work> Message-ID: <1037400177.9611.119.camel@work> Thanks to all for help. I've aked and obtained the delegation ip6.int for my /32 and updated all my libresolv. Thanks, Max On Thu, 2002-11-14 at 23:30, Max Gargani wrote: > Hi all, > > maybe this is not the right place or maybe I wrong something but since > RIPE NCC gave to my company the reverse delegation for the allocated /32 > ip6.arpa, all protocols such ssh, ircd etc etc, can't resolve the > addresses. > > >From named log I see ssh & co ask to resolve > i.p.v.6.a.d.d.r.e.s.s.ip6.int but all RIRs allocations are ip6.arpa. > > Anyone with same problem? > > Thanks, > > Max > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > > > >>> Edisontel Spa. - Il messaggio è stato controllato dal sistema > AntiVirus [a] <<< > > From jeroen@unfix.org Sat Nov 16 00:09:29 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Sat, 16 Nov 2002 01:09:29 +0100 Subject: [6bone] Meeting agenda in Atlanta In-Reply-To: Message-ID: <000901c28d04$70401a30$210d640a@unfix.org> Robert J. Rockell wrote: > -Michel presents thoughts on state of 6bone (10 minutes) See below :) > referenced drafts for your pre-reading: > > 6bone-Mess: > http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-01.txt > 2772 re-write: > http://www.6bone.net/misc/draft-ietf-rockell-6bone-ops-guide-00.txt > > Note: 2772 re-write may be Ipv4 accessible only (not my server, complaints > to admin of www.6bone.net :) ). With respect to the 'state' of the 6bone, this would really mean it is quite unstable. Fortunatly a fetch on IPv4 only fixes it but that is quite bad don't you think ? :) Just a quick 'fix': by IP (fortunatly it's either the default vhost or there are no others) http://131.243.129.43/misc/draft-ietf-rockell-6bone-ops-guide-00.txt Working over IPv4 + IPv6 and it is the same box: http://www.ipng.nl/~jeroen/draft-ietf-rockell-6bone-ops-guide-00.txt Some relevant comments: - There is mention of the multi6 group, but not to the ipv6mh group. They will be conducting experiments soon too (Michel Py has more info) Ofcourse they are not a 'official' ietf working group. - 7.1.c: "Fully maintained DNS forward (AAAA) and reverse (ip6.int and ip6.arpa) entries for all of the Applicant's router(s)." I've added ip6.arpa there to push the RIR's to delegate it, we might let all pTLA's create working ip6.arpa reverses already so that when the reverse gets delegated it all starts working in one go without further ado. I've added "all ... routers" just to make it more clear. I've also removed the "at least one host" part as that's something most people will do by them selves and doesn't really make it more visible or stable to whom the addresses belong. Notez bien that one can easily setup a wildcard reverse catch so that a complete block is handled in one go eg: *.0.c.e.f.ip6.arpa. PTR unassigned.example.net. Though one has to wonder where the use is for such a catch'em-all. - 7.1.d: "A fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing the Applicant's IPv6 services. This server must be IPv6 pingable. This pingable host should be entered into the whois object for this site under all the relevant 'application' lines. This website must also list correct and working contact addresses for technical problems. These must match the records in the whois database. The site should have a looking glass available allowing checkups of reachability and ghost route control." The last sentence will hopefully force people to enter those records into the database thus allowing the many automatic ping scripts to work much better, currently about 90% of those "application: ping " lines are non-working (dns fallout, non-existing hosts, you name it). The lookingglass part is actually quite important as it gives many operators an insight into the routing tables and their issues at a remote site. And this might at least give a view onto the problem where numberous ghostroutes have been seen but couldn't be tracked down because the site's operators where not available. LG's are 24x7, people are not. One will probably want to split up the additions if one takes them into account :) Greets, Jeroen From Robert.Kiessling@de.easynet.net Sat Nov 16 15:23:44 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 16 Nov 2002 15:23:44 +0000 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> Message-ID: Here is a rather radical proposal: Peerings between 6bone sites MUST NOT carry any other routes apart from 3FFE and a summary route for 2001/3. This achieves a number of goals: - it provides a clear distinction between the experimental part from the rest of the IPv6 world - interconnections between 6bone and the rest of the IPv6 world can still be numerous and reliable - existing services in the 3FFE space can be accessed from everywhere, noone is cut off - cost-free trial implementation is still possible, but transition to RIR space is encouraged - since RIR sites can filter RIR space from peerings with 6bone sites, BGP problems from 6bone sites will not affect the global network and last but not least - it's a very simple, verifyable criterion Of course, all is not gold, so there are some drawbacks: - 6bone sites will no longer see 2001 routes, so they will need to do "closest exit" routing to the nearest RIR site. - peerings between dual (RIR & 6bone) sites will not carry 2001 space - propably others I haven't thought of Robert From itojun@iijlab.net Sat Nov 16 16:00:08 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Sun, 17 Nov 2002 01:00:08 +0900 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: Robert.Kiessling's message of 16 Nov 2002 15:23:44 GMT. Message-ID: <20021116160008.27EFA4B24@coconut.itojun.org> >Here is a rather radical proposal: > Peerings between 6bone sites MUST NOT carry any other routes apart > from 3FFE and a summary route for 2001/3. do you mean "and a summary route for 2001::/16 and 2002::/16", or "2000::/3"? itojun From nicolas.deffayet@ndsoftware.net Sun Nov 17 00:25:05 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 17 Nov 2002 01:25:05 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> Message-ID: <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> On Sat, 2002-11-16 at 16:23, Robert Kiessling wrote: > Here is a rather radical proposal: > > Peerings between 6bone sites MUST NOT carry any other routes apart > from 3FFE and a summary route for 2001/3. You can have unstability problems with RIR space... A lot of ISP use their RIR space for do experimental stuff (it's more easy for a LIR to get a sTLA than a pTLA for do tests...) pTLA owner have IPv6 experience: >From RFC2772 1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period the Applicant must be operationally providing the following: sTLA owner can don't have IPv6 experience because it's not a requierement for get a sTLA. I think that your solution is not good and will kill the 6bone. Why limit 6bone space if the pTLA are expected to provide production quality service ? >From RFC2772: The following rules apply to qualify for a 6Bone pTLA allocation. It should be recognized that holders of 6Bone pTLA allocations are expected to provide production quality backbone network services for the 6Bone. I think that it's better to remplace "6Bone pTLA allocations are expected to provide production quality..." by "6Bone pTLA allocations MUST provide production quality...". I don't understand how RIR space can get problems with 6bone space... Please explain me. My router will don't do better announces with RIR space than 6bone space.... -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From michel@arneill-py.sacramento.ca.us Sun Nov 17 06:52:44 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 16 Nov 2002 22:52:44 -0800 Subject: [6bone] Meeting agenda in Atlanta Message-ID: <2B81403386729140A3A899A8B39B046405E482@server2000> > So we will meet over lunch on Tuesday, at a room > to be decided when I arrive and ask the IETF > organizers which one I can use. Given the > possibility of a projector that works, I do carry a projector along with my laptop, making virtually any place with a power outlet suitable for a meeting. The usage of my Infocus is not free, but alternative payment methods such as a free Sprint T1 service to my home (with native IPv6, needless to say) or a red wine and steak dinner are negotiable :-) Michel. From Robert.Kiessling@de.easynet.net Sun Nov 17 12:57:36 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 17 Nov 2002 12:57:36 +0000 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> Message-ID: Nicolas DEFFAYET writes: > On Sat, 2002-11-16 at 16:23, Robert Kiessling wrote: > > Here is a rather radical proposal: > > > > Peerings between 6bone sites MUST NOT carry any other routes apart > > from 3FFE and a summary route for 2001/3. > > You can have unstability problems with RIR space... You can have stability problems in IPv4. Does it matter for this discussion? No. What matters is what actually happens, i.e. what is *likely* to cause problems. And here we saw several instances of unmaintained and badly responsive 6bone site, and sites running two-year old copies of depricated BGP software. For example, all of the LIRs I have spoken to understand the problem with long-distance tunnels and are getting rid of them, while at the same time a 6bone site proudly announced to have more than 90 tunnels. > A lot of ISP use their RIR space for do experimental stuff (it's more > easy for a LIR to get a sTLA than a pTLA for do tests...) I anticipate filtering of announcementes from such sites in RIR space, which solves this problem. > sTLA owner can don't have IPv6 experience because it's not a > requierement for get a sTLA. Entities operating RIR allocations will have BGP experience, which is more relevent. And they have a view and sense of real network topology. > I think that your solution is not good and will kill the 6bone. It might be more productive if you explained concretely why you think it's a bad idea. I don't see any indication why this would "kill 6bone". What do you mean by this? > Why limit 6bone space if the pTLA are expected to provide production > quality service ? In all practical terms, this requirement from 2772 is ignored. As it has to be, since "production quality" is too vague to be acted upon. And as the discussion here shows, there is reluctance to detail this, e.g. by requiring 24h response time. > I don't understand how RIR space can get problems with 6bone space... > Please explain me. I don't understand your sentence, sorry. > My router will don't do better announces with RIR space than 6bone > space.... You don't get RIR space because you are not LIR, don't meet the requirements to become LIR and most likely wouldn't be prepared to pay for it. In other words, you operate it as a hobby, while LIRs operate professionally. And it's not just you, it's many other 6bone sites too. This is not to say that this is a bad thing. In the opposite, much good came out of private initiative. However, there are global operational impacts, and they must be limited. RIRs have the background of production network operation in the IPv4 world. Serious, quality-oriented IPv6 backbone operation is what we now need to bring IPv6 forward. Robert From rrockell@sprint.net Wed Nov 13 21:59:08 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Wed, 13 Nov 2002 16:59:08 -0500 (EST) Subject: [6bone] (no subject) Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1483920592-1037224748=:516 Content-Type: TEXT/PLAIN; charset=US-ASCII New 2772 draft. Take a look. Look for "WOOP" in the body for notes. Largely, only the pTLA requirements are re-written. Send to me with comments, or the list. We beyond the dealine for submission, but mayve this can serve as good discussion points for Tuesday lunch meeting at IETF. Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- ---559023410-1483920592-1037224748=:516 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-ietf-rockell-6bone-ops-guide-00.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-ietf-rockell-6bone-ops-guide-00.txt" TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFIuIFJvY2tlbGwNCklOVEVSTkVUIERSQUZUICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT cHJpbnRMaW5rDQoNCkNhdGVnb3J5ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmZvcm1hdGlvbmFsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTm92ZW1iZXIsIDIwMDIgDQoNCg0KICAgICAgICAg ICAgICAgICAgNkJvbmUgUm91dGluZyBHdWlkZWxpbmVzIFJldmlzaXRlZCAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAoMjc3Mi1iaXM/KQ0KDQoN ClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBtZW1vIHByb3ZpZGVz IGluZm9ybWF0aW9uIGZvciB0aGUgSW50ZXJuZXQgY29tbXVuaXR5LiAgSXQg ZG9lcw0KICAgbm90IHNwZWNpZnkgYW4gSW50ZXJuZXQgc3RhbmRhcmQgb2Yg YW55IGtpbmQuICBEaXN0cmlidXRpb24gb2YgdGhpcw0KICAgbWVtbyBpcyB1 bmxpbWl0ZWQuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMCkuICBBbGwgUmlnaHRz IFJlc2VydmVkLg0KDQpBYnN0cmFjdA0KDQogICBUaGUgNkJvbmUgaXMgYW4g SXB2NiB0ZXN0YmVkIHRvIGFzc2lzdCBpbiB0aGUgZXZvbHV0aW9uIGFuZA0K ICAgZGVwbG95bWVudCBvZiBJUHY2LiBCZWNhdXNlIG9mIHRoaXMsIGl0IGlz IGltcG9ydGFudCB0aGF0IHRoZSBjb3JlDQogICBiYWNrYm9uZSBvZiB0aGUg SVB2NiBuZXR3b3JrIG1haW50YWluIHN0YWJpbGl0eSwgYW5kIHRoYXQgYWxs DQogICBvcGVyYXRvcnMgaGF2ZSBhIGNvbW1vbiBzZXQgb2YgcnVsZXMgYW5k IGd1aWRlbGluZXMgYnkgd2hpY2ggdG8NCiAgIGRlcGxveSBJUHY2IHJvdXRp bmcgZXF1aXBtZW50Lg0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEg c2V0IG9mIGd1aWRlbGluZXMgZm9yIGFsbCA2Ym9uZSByb3V0aW5nDQogICBl cXVpcG1lbnQgb3BlcmF0b3JzIHRvIHVzZSBhcyBhIHJlZmVyZW5jZSBmb3Ig ZWZmaWNpZW50IGFuZCBzdGFibGUNCiAgIGRlcGxveW1lbnQgb2YgNmJvbmUg cm91dGluZyBzeXN0ZW1zLiBBcyB0aGUgY29tcGxleGl0eSBvZiB0aGUgNkJv bmUNCiAgIGdyb3dzLCB0aGUgYWRoZXJlbmNlIHRvIGEgY29tbW9uIHNldCBv ZiBydWxlcyBiZWNvbWVzIGluY3JlYXNpbmdseQ0KICAgaW1wb3J0YW50IGlu IG9yZGVyIGZvciBhbiBlZmZpY2llbnQsIHNjYWxhYmxlIGJhY2tib25lIHRv IGV4aXN0Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuIEludHJvZHVjdGlvbi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uICAyDQogICAyLiBTY29wZSBvZiB0aGlzIGRvY3VtZW50Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgMw0KICAgMy4gQ29t bW9uIFJ1bGVzIGZvciB0aGUgNmJvbmUuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4gIDMNCiAgICAgICAzLjEgTGluay1sb2NhbCBwcmVm aXhlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICAz DQogICAgICAgMy4yIFNpdGUtbG9jYWwgcHJlZml4ZXMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAgNA0KICAgICAgIDMuMyBMb29w YmFjayBhbmQgdW5zcGVjaWZpZWQgcHJlZml4ZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4gIDUNCiAgICAgICAzLjQgTXVsdGljYXN0IHByZWZpeGVzLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICA1DQogICAg ICAgMy41IElQdjQgY29tcGF0aWJsZSBwcmVmaXhlcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLiAgNQ0KICAgICAgIDMuNiBJUHY0LW1hcHBl ZCBwcmVmaXhlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4gIDYNCiAgICAgICAzLjcgRGVmYXVsdCByb3V0ZXMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICA2DQogICAgICAgMy44 IFlldCB1bmRlZmluZWQgdW5pY2FzdCBwcmVmaXhlcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLiAgNg0KICAgICAgIDMuOSBJbnRlci1zaXRlIGxpbmtz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gIDYN CiAgICAgICAzLjEwIDZ0bzQgUHJlZml4ZXMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uICA3DQogICAgICAgMy4xMSBBZ2dy ZWdhdGlvbiAmIGFkdmVydGlzZW1lbnQgaXNzdWVzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLiAgNw0KICAgNC4gUm91dGluZyBQb2xpY2llcyBmb3IgdGhlIDZi b25lLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gIDcNCiAgIDUu IFRoZSA2Qm9uZSBSZWdpc3RyeS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uICA4DQogICA2LiBHdWlkZWxpbmVzIGZvciBu ZXcgc2l0ZXMgam9pbmluZyB0aGUgNkJvbmUuLi4uLi4uLi4uLi4uLi4uLi4u LiAgOQ0KICAgNy4gR3VpZGVsaW5lcyBmb3IgNkJvbmUgcFRMQSBzaXRlcy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gIDkNCiAgIDguIDZCb25l IE9wZXJhdGlvbnMgZ3JvdXAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uIDExDQogICAgICA4LjEgNkJvbmUgU3RlZXJpbmcgR3Jv dXAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAxMQ0K ICAgOS4gQ29tbW9uIHJ1bGVzIGVuZm9yY2VtZW50IGZvciB0aGUgNmJvbmUu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMTENCiAgIDEwLiBGaWx0ZXJpbmcg b24gdGhlIDZib25lOyBHdWlkZWxpbmVzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uIDEyIA0KICAgICAgICAxMC4xIHBUTEEgRmlsdGVyaW5nIEd1aWRl bGluZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMTINCiAgIDEx LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uIA0KICAgMTIuIFJlZmVyZW5jZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4g DQogICAxMy4gQXV0aG9ycycgQWRkcmVzc2VzLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiANCiAgIDE0LiBGdWxsIENvcHly aWdodCBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uIA0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIDZCb25lIGlz IGFuIElQdjYgdGVzdGJlZCB0byBhc3Npc3QgaW4gdGhlIGV2b2x1dGlvbiBh bmQNCiAgIGRlcGxveW1lbnQgb2YgSVB2Ni4gQmVjYXVzZSBvZiB0aGlzLCBp dCBpcyBpbXBvcnRhbnQgdGhhdCB0aGUgY29yZQ0KICAgYmFja2JvbmUgb2Yg dGhlIElQdjYgbmV0d29yayBtYWludGFpbiBzdGFiaWxpdHksIGFuZCB0aGF0 IGFsbA0KICAgb3BlcmF0b3JzIGhhdmUgYSBjb21tb24gc2V0IG9mIHJ1bGVz IGFuZCBndWlkZWxpbmVzIGJ5IHdoaWNoIHRvDQogICBkZXBsb3kgSVB2NiBy b3V0aW5nIGVxdWlwbWVudC4NCg0KICAgVGhpcyBkb2N1bWVudCBwcm92aWRl cyBhIHNldCBvZiBndWlkZWxpbmVzIGZvciBhbGwgNmJvbmUgcm91dGluZw0K ICAgZXF1aXBtZW50IG9wZXJhdG9ycyB0byB1c2UgYXMgYSByZWZlcmVuY2Ug Zm9yIGVmZmljaWVudCBhbmQgc3RhYmxlDQogICBkZXBsb3ltZW50IG9mIDZi b25lIHJvdXRpbmcgc3lzdGVtcy4gQXMgdGhlIGNvbXBsZXhpdHkgb2YgdGhl IDZCb25lDQogICBncm93cywgdGhlIGFkaGVyZW5jZSB0byBhIGNvbW1vbiBz ZXQgb2YgcnVsZXMgYmVjb21lcyBpbmNyZWFzaW5nbHkNCiAgIGltcG9ydGFu dCBpbiBvcmRlciBmb3IgYW4gZWZmaWNpZW50LCBzY2FsYWJsZSBiYWNrYm9u ZSB0byBleGlzdC4NCg0KICAgVGhpcyBkb2N1bWVudCB1c2VzIEJHUC00IHdp dGggTXVsdGlwcm90b2NvbCBFeHRlbnNpb25zIGZvciBCR1AtNCBhcw0KICAg ZGVmaW5lZCBbUkZDIDIyODNdLCBjb21tb25seSByZWZlcnJlZCB0byBhcyBC R1A0KywgYXMgdGhlIGN1cnJlbnRseQ0KICAgYWNjZXB0ZWQgRUdQLg0KDQog ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VM RCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IGRlc2NyaWJlZCBpbiBbUkZDIDIxMTldLg0KDQoNCg0KMi4gU2NvcGUgb2Yg dGhpcyBkb2N1bWVudA0KDQogICBUaGlzIGRvY3VtZW50IGlzIGEgYmVzdC1w cmFjdGljZXMgSW5mb3JtYXRpb25hbCBkb2N1bWVudCBhaW1lZCBhdA0KICAg SVB2NiBlbnRpdGllcyB3aGljaCBvcGVyYXRlIHVuZGVyIHRoZSA2Qm9uZSBJ UHY2IHRlc3RiZWQgVExBDQogICBhbGxvY2F0aW9uLg0KDQozLiBDb21tb24g UnVsZXMgZm9yIHRoZSA2Ym9uZQ0KDQogICBUaGlzIHNlY3Rpb24gZGV0YWls cyBjb21tb24gcnVsZXMgZ292ZXJuaW5nIHRoZSByb3V0aW5nIG9mIHRoZSA2 Qm9uZS4NCiAgIFRoZXkgYXJlIGRlcml2ZWQgZnJvbSB0aGUgaXNzdWVzIGVu Y291bnRlcmVkIG9uIHRoZSA2Qm9uZSwgd2l0aA0KICAgcmVzcGVjdCB0byB0 aGUgcm91dGVzIGFkdmVydGlzZWQsIGhhbmRsaW5nIG9mIHNwZWNpYWwgYWRk cmVzc2VzLCBhbmQNCiAgIGFnZ3JlZ2F0aW9uOg0KDQogICAgICAxKSBsaW5r IGxvY2FsIHByZWZpeGVzDQoNCiAgICAgIDIpIHNpdGUgbG9jYWwgcHJlZml4 ZXMNCg0KICAgICAgMykgbG9vcGJhY2sgYW5kIHVuc3BlY2lmaWVkIHByZWZp eGVzDQoNCiAgICAgIDQpIG11bHRpY2FzdCBwcmVmaXhlcw0KDQogICAgICA1 KSBJUHY0LWNvbXBhdGlibGUgcHJlZml4ZXMNCg0KICAgICAgNikgSVB2NC1t YXBwZWQgcHJlZml4ZXMNCg0KICAgICAgNykgZGVmYXVsdCByb3V0ZXMNCg0K ICAgICAgOCkgeWV0IHVuZGVmaW5lZCB1bmljYXN0IHByZWZpeGVzIChmcm9t IGEgZGlmZmVyZW50IC8zIHByZWZpeCkNCg0KICAgICAgOSkgaW50ZXItc2l0 ZSBsaW5rcyBpc3N1ZXMNCg0KICAgICAgMTApIDZ0bzQgcHJlZml4ZXMNCg0K ICAgICAgMTEpIGFnZ3JlZ2F0aW9uICYgYWR2ZXJ0aXNlbWVudCBpc3N1ZXMN Cg0KMy4xIExpbmstbG9jYWwgcHJlZml4ZXMNCg0KICAgVGhpcyBsaW5rLWxv Y2FsIHByZWZpeCAoRkU4MDo6LzEwKSBNVVNUIE5PVCBiZSBhZHZlcnRpc2Vk IHRocm91Z2gNCiAgIGVpdGhlciBhbiBJR1Agb3IgYW4gRUdQLiAgVW5kZXIg bm8gY2lyY3Vtc3RhbmNlIHNob3VsZCB0aGlzIHByZWZpeCBiZQ0KICAgc2Vl biBpbiB0aGUgNkJvbmUgYmFja2JvbmUgcm91dGluZyB0YWJsZS4NCg0KICAg QnkgZGVmaW5pdGlvbiwgdGhlIGxpbmstbG9jYWwgcHJlZml4IGhhcyBhIHNj b3BlIGxpbWl0ZWQgdG8gYQ0KICAgc3BlY2lmaWMgbGluay4gU2luY2UgdGhl IHByZWZpeCBpcyB0aGUgc2FtZSBvbiBhbGwgSVB2NiBsaW5rcywNCiAgIGFk dmVydGlzaW5nIGl0IGluIGFueSByb3V0aW5nIHByb3RvY29sIGRvZXMgbm90 IG1ha2Ugc2Vuc2UgYW5kLA0KICAgd29yc2UsIG1heSBpbnRyb2R1Y2UgbmFz dHkgZXJyb3IgY29uZGl0aW9ucy4NCg0KICAgV2VsbCBrbm93biBjYXNlcyB3 aGVyZSBsaW5rLWxvY2FsIHByZWZpeGVzIGNvdWxkIGJlIGFkdmVydGlzZWQg YnkNCiAgIG1pc3Rha2UgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0 bzoNCg0KICAgLSAgYSByb3V0ZXIgYWR2ZXJ0aXNpbmcgYWxsIGRpcmVjdGx5 IGNvbm5lY3RlZCBuZXR3b3JrIHByZWZpeGVzDQogICAgICBpbmNsdWRpbmcg dGhlIGxpbmstbG9jYWwgb25lDQoNCiAgIC0gIHN1Ym5ldHRpbmcgb2YgdGhl IGxpbmstbG9jYWwgcHJlZml4DQoNCiAgIEluIHN1Y2ggY2FzZXMsIHZlbmRv cnMgc2hvdWxkIGJlIHVyZ2VkIHRvIGNvcnJlY3QgdGhlaXIgY29kZS4gV2hp bGUNCiAgIHZlbmRvcnMgc2hvdWxkIGJlIGVuY291cmFnZWQgdG8gZml4IHRo ZSBwcm9ibGVtLCB0aGUgdWx0aW1hdGUNCiAgIHJlc3BvbnNpYmlsaXR5IGxp ZXMgb24gdGhlIG9wZXJhdG9yIG9mIHRoYXQgSVB2NiBzaXRlIHRvIGNvcnJl Y3QgdGhlDQogICBwcm9ibGVtIHRocm91Z2ggd2hhdGV2ZXIgbWVhbnMgbmVj ZXNzYXJ5Lg0KDQogICBTaG91bGQgYSBwVExBIGRpc2NvdmVyIGxpbmstbG9j YWwgcHJlZml4ZXMgY29taW5nIGZyb20gYW5vdGhlciBwVExBLA0KICAgaXQg aXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBwVExBIGxlYWtpbmcgdGhl IHJvdXRlcyB0byBmaWx0ZXINCiAgIHRoZXNlLCBhbmQgY29ycmVjdCB0aGUg cHJvYmxlbSBpbiBhIHRpbWVseSBmYXNoaW9uLiBTaG91bGQgYSBwVExBDQog ICBkaXNjb3ZlciB0aGF0IGEgZG93bnN0cmVhbSBvZiB0aGF0IHBUTEEgaXMg bGVha2luZyBsaW5rLWxvY2FsDQogICBwcmVmaXhlcywgaXQgaXMgdGhlIHBU TEEncyByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB0aGVzZQ0KICAg cHJlZml4ZXMgYXJlIG5vdCBsZWFrZWQgdG8gb3RoZXIgcFRMQSdzLCBvciB0 byBvdGhlciBkb3duc3RyZWFtcyBvZg0KICAgdGhhdCBwVExBLg0KDQogICBG YWlsdXJlIHRvIGZpbHRlciBzdWNoIHJvdXRlcyBpbiBhIHRpbWVseSBmYXNo aW9uIG1heSByZXN1bHQgaW4gdGhlDQogICBtYW51YWwgc2h1dHRpbmcgZG93 biBvZiBCR1A0KyBzZXNzaW9ucyB0byB0aGF0IHBUTEEsIGZyb20gb3RoZXIN CiAgIHBUTEEncywgb3IgcmVtb3ZhbCBvZiBvbmUncyBwVExBIGRlbGVnYXRp b24uDQoNCiAgIChBbHNvLCBpdCBpcyBlYWNoIHBUTEEsIHBOTEEsIGFuZCBl bmQtc2l0ZSdzIHJlc3BvbnNpYmlsaXR5IHRvIG5vdA0KICAgb25seSBmaWx0 ZXIgdGhlaXIgb3duIEJHUDQrIHNlc3Npb25zIGFwcHJvcHJpYXRlbHkgdG8g cGVlcnMsIGJ1dCB0bw0KICAgZmlsdGVyIHJvdXRlcyBjb21pbmcgZnJvbSBw ZWVycyBhcyB3ZWxsLCBhbmQgdG8gb25seSBhbGxvdyB0aG9zZQ0KICAgcm91 dGVzIHRoYXQgZml0IHRoZSBhZ2dyZWdhdGlvbiBtb2RlbCwgYW5kIGRvIG5v dCBjYXVzZSBvcGVyYXRpb25hbA0KICAgcHJvYmxlbXMpLg0KDQozLjIgU2l0 ZS1sb2NhbCBwcmVmaXhlcw0KDQogICBTaXRlIGxvY2FsIHByZWZpeGVzIChp biB0aGUgRkVDMDo6LzEwIHJhbmdlKSBNQVkgYmUgYWR2ZXJ0aXNlZCBieQ0K ICAgSUdQJ3Mgb3IgRUdQJ3Mgd2l0aGluIGEgc2l0ZS4gVGhlIHByZWNpc2Ug ZGVmaW5pdGlvbiBvZiBhIHNpdGUgaXMNCiAgIG9uZ29pbmcgd29yayBvZiB0 aGUgSVBuZyB3b3JraW5nIGdyb3VwLCBidXQgc2hvdWxkIGdlbmVyYWxseSBp bmNsdWRlDQogICBhIGdyb3VwIG9mIG5vZGVzIHRoYXQgYXJlIG9wZXJhdGlu ZyB1bmRlciBvbmUgYWRtaW5pc3RyYXRvciBvciBncm91cA0KICAgb2YgYWRt aW5pc3RyYXRvcnMsIG9yIGEgZ3JvdXAgb2Ygbm9kZXMgd2hpY2ggYXJlIHVz ZWQgZm9yIGEgY29tbW9uDQogICBwdXJwb3NlLg0KDQogICBTaXRlLWxvY2Fs IHByZWZpeGVzIE1VU1QgTk9UIGJlIGFkdmVydGlzZWQgYWNyb3NzIHRyYW5z aXQgcE5MQXMsDQogICBwVExBcywgb3IgbGVhZi1zaXRlcy4NCg0KICAgQWdh aW4sIHNob3VsZCBzaXRlLWxvY2FsIHByZWZpeGVzIGJlIGxlYWtlZCBvdXRz aWRlIG9mIGEgZ2l2ZW4gc2l0ZSwNCiAgIGl0IGlzIHRoZSByZXNwb25zaWJp bGl0eSBvZiB0aGUgc2l0ZSB0byBmaXggdGhlIHByb2JsZW0gaW4gYSB0aW1l bHkNCiAgIG1hbm5lciwgZWl0aGVyIHRocm91Z2ggZmlsdGVycywgb3Igdmlh IG90aGVyIG1lYW5zIHdoaWNoIHJlbW92ZSB0aGUNCiAgIG9wZXJhdGlvbmFs IGltcGFjdCB0aGF0IHRob3NlIHByZWZpeGVzIGhhZCBvbiB0aGUgcGVlcmlu ZyBzaXRlcw0KICAgaW52b2x2ZWQuIEhvd2V2ZXIsIGV2ZXJ5IHNpdGUgU0hP VUxEIGZpbHRlciBub3Qgb25seSBvdXRib3VuZCBvbg0KICAgdGhlaXIgRUdQ LCBidXQgYWxzbyBpbmJvdW5kLCBpbiBvcmRlciB0byBlbnN1cmUgcHJvcGVy IHJvdXRpbmcNCiAgIGFubm91bmNlbWVudHMgYXJlIG5vdCBvbmx5IHNlbnQs IGJ1dCBhbHNvIHJlY2VpdmVkLg0KDQozLjMgTG9vcGJhY2sgYW5kIHVuc3Bl Y2lmaWVkIHByZWZpeGVzDQoNCiAgIFRoZSBsb29wYmFjayBwcmVmaXggKDo6 MS8xMjgpIGFuZCB0aGUgdW5zcGVjaWZpZWQgcHJlZml4ICg6OjAvMTI4KQ0K ICAgTVVTVCBOT1QgYmUgYWR2ZXJ0aXNlZCBieSBhbnkgcm91dGluZyBwcm90 b2NvbC4NCg0KICAgVGhlIHNhbWUgcmVzcG9uc2liaWxpdHkgbGllcyB3aXRo IHRoZSBwYXJ0eSBndWlsdHkgb2YgYWR2ZXJ0aXNpbmcgdGhlDQogICBsb29w YmFjayBvciB1bnNwZWNpZmllZCBwcmVmaXggYXMgaW4gU2VjdGlvbiAzLjEg YW5kIDMuMi4NCg0KMy40IE11bHRpY2FzdCBwcmVmaXhlcw0KDQogICBNdWx0 aWNhc3QgcHJlZml4ZXMgTVVTVCBOT1QgYmUgYWR2ZXJ0aXNlZCBieSBhbnkg dW5pY2FzdCByb3V0aW5nDQogICBwcm90b2NvbC4gTXVsdGljYXN0IHJvdXRp bmcgcHJvdG9jb2xzIGFyZSBkZXNpZ25lZCB0byByZXNwZWN0IHRoZQ0KICAg c2VtYW50aWNzIG9mIG11bHRpY2FzdCBhbmQgTVVTVCB0aGVyZWZvcmUgYmUg dXNlZCB0byByb3V0ZSBwYWNrZXRzDQogICB3aXRoIG11bHRpY2FzdCBkZXN0 aW5hdGlvbiBhZGRyZXNzZXMgKGluIHRoZSByYW5nZSBvZiBGRjAwOjovOCku DQoNCiAgIE11bHRpY2FzdCBhZGRyZXNzIHNjb3BlcyBNVVNUIGJlIHJlc3Bl Y3RlZCBvbiB0aGUgNkJvbmUuICBPbmx5IGdsb2JhbA0KICAgc2NvcGUgbXVs dGljYXN0IGFkZHJlc3NlcyBNQVkgYmUgcm91dGVkIGFjcm9zcyB0cmFuc2l0 IHBOTEFzIGFuZA0KICAgcFRMQXMuICBUaGVyZSBpcyBubyByZXF1aXJlbWVu dCBvbiBhIHBUTEEgdG8gcm91dGUgbXVsdGljYXN0IHBhY2tldHMNCiAgIGF0 IHRoZSB0aW1lIG9mIHRoZSB3cml0aW5nIG9mIHRoaXMgbWVtby4NCg0KICAg T3JnYW5pemF0aW9uLWxvY2FsIG11bHRpY2FzdHMgKGluIHRoZSBGRjA4Ojov MTYgb3IgRkYxODo6LzE2IHJhbmdlcykNCiAgIE1BWSBiZSByb3V0ZWQgYWNy b3NzIGEgcE5MQSB0byBpdHMgbGVhZiBzaXRlcy4NCg0KICAgU2l0ZS1sb2Nh bCBtdWx0aWNhc3RzIE1VU1QgTk9UIGJlIHJvdXRlZCB0b3dhcmQgdHJhbnNp dCBwTkxBcyBvcg0KICAgcFRMQXMuDQoNCiAgIExpbmstbG9jYWwgbXVsdGlj YXN0cyBhbmQgbm9kZS1sb2NhbCBtdWx0aWNhc3RzIE1VU1QgTk9UIGJlIHJv dXRlZCBhdA0KICAgYWxsLg0KDQozLjUgSVB2NCBjb21wYXRpYmxlIHByZWZp eGVzDQoNCiAgIFNpdGVzIG1heSBjaG9vc2UgdG8gdXNlIElQdjQgY29tcGF0 aWJsZSBhZGRyZXNzZXMgKDo6YS5iLmMuZCB3aGVyZQ0KICAgYS5iLmMuZCBy ZXByZXNlbnRzIHRoZSBvY3RldHMgb2YgYW4gSVB2NCBhZGRyZXNzKSBpbnRl cm5hbGx5LiBBcw0KICAgdGhlcmUgaXMgbm8gcmVhbCByYXRpb25hbGUgdG9k YXkgZm9yIGRvaW5nIHNvLCB0aGVzZSBhZGRyZXNzIFNIT1VMRA0KICAgTk9U IGJlIHVzZWQgb3Igcm91dGVkIGluIHRoZSA2Qm9uZS4NCg0KICAgVGhlIDo6 Lzk2IElQdjQtY29tcGF0aWJsZSBwcmVmaXhlcyBNQVkgYmUgYWR2ZXJ0aXNl ZCBieSBJR1BzLg0KDQogICBJUHY0IGNvbXBhdGlibGUgcHJlZml4ZXMgTVVT VCBOT1QgYmUgYWR2ZXJ0aXNlZCBieSBFR1BzIHRvIHRyYW5zaXQNCiAgIHBO TEFzIG9yIHBUTEFzLg0KDQogICBTaG91bGQgOjovOTYgSVB2NC1jb21wYXRp YmxlIHByZWZpeGVzIGJlIGxlYWtlZCBpbnRvIGFuIEVHUCwgaXQgaXMNCiAg IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgcGFydHkgd2hvIGlzIGFkdmVy dGlzaW5nIHRoZSByb3V0ZSB0byBmaXgNCiAgIHRoZSBwcm9ibGVtLCBlaXRo ZXIgdGhyb3VnaCBwcm9wZXIgZmlsdGVycywgb3IgdGhyb3VnaCBvdGhlciBt ZWFucywNCiAgIHdoaWxlIGl0IHJlbWFpbnMgaW4gdGhlIGJlc3QgaW50ZXJl c3Qgb2YgYWxsIHBhcnRpY2lhcGFudHMgb2YgdGhlDQogICA2Qm9uZSB0byBm aWx0ZXIgYm90aCBvdXRib3VuZCBhbmQgaW5ib3VuZCBhdCB0aGVpciBJR1Ag Ym9yZGVycy4NCg0KMy42IElQdjQtbWFwcGVkIHByZWZpeGVzDQoNCiAgIElQ djQtbWFwcGVkIHByZWZpeGVzICg6OkZGRkY6YS5iLmMuZCB3aGVyZSBhLmIu Yy5kIHJlcHJlc2VudHMgdGhlDQogICBvY3RldHMgb2YgYW4gSVB2NCBhZGRy ZXNzKSBNQVkgYmUgYWR2ZXJ0aXNlZCBieSBJR1BzIHdpdGhpbiBhIHNpdGUu DQogICBJdCBtYXkgYmUgdXNlZnVsIGZvciBzb21lIElQdjYgb25seSBub2Rl cyB3aXRoaW4gYSBzaXRlIHRvIGhhdmUgc3VjaA0KICAgYSByb3V0ZSBwb2lu dGluZyB0byBhIHRyYW5zbGF0aW9uIGRldmljZSwgdG8gYWlkIGluIGRlcGxv eW1lbnQgb2YNCiAgIElQdjYuDQoNCiAgIElQdjQtbWFwcGVkIHByZWZpeGVz IE1VU1QgTk9UIGJlIGFkdmVydGlzZWQgYnkgRUdQcy4NCg0KMy43IERlZmF1 bHQgcm91dGVzDQoNCiAgIDZCb25lIGNvcmUgcFRMQSByb3V0ZXJzIE1VU1Qg YmUgZGVmYXVsdC1mcmVlLg0KDQogICBwVExBcyBNQVkgYWR2ZXJ0aXNlIGEg ZGVmYXVsdCByb3V0ZSB0byBhbnkgZG93bnN0cmVhbSBwZWVyIChub24tcFRM QQ0KICAgc2l0ZSkuIFRyYW5zaXQgcE5MQXMgTUFZIGFkdmVydGlzZSBhIGRl ZmF1bHQgcm91dGUgdG8gYW55IG9mIHRoZWlyDQogICBkb3duc3RyZWFtcyAo b3RoZXIgdHJhbnNpdCBwTkxBIG9yIGxlYWYgc2l0ZSkuDQoNCiAgIFNob3Vs ZCBhIGRlZmF1bHQgcm91dGUgYmUgcmVkaXN0cmlidXRlZCBpbnRvIGFuIEVH UCBhbmQgZm91bmQgb24gYW55DQogICBwVExBIEVHUCBzZXNzaW9ucywgaXQg aXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBwVExBIHRvIGZpeCB0aGlz DQogICBwcm9ibGVtIGltbWVkaWF0ZWx5IHVwb24gcmVhbGl6YXRpb24gb2Yg dGhlIHJvdXRlJ3MgZXhpc3RlbmNlLCBhbmQNCiAgIHRoZSByZXNwb25zaWJp bGl0eSBvZiB0aGUgZ3VpbHR5IHBUTEEgdG8gcHVzaCB0aGUgZW50aXR5IGZy b20gd2hpY2gNCiAgIHRoZSBkZWZhdWx0IHJvdXRlIHdhcyBvcmlnaW5hdGVk LCBzaG91bGQgdGhlIGRlZmF1bHQgcm91dGUgaGF2ZQ0KICAgb3JpZ2luYXRl ZCBmcm9tIGRvd25zdHJlYW0gb2YgYSBwVExBLg0KDQozLjggWWV0IHVuZGVm aW5lZCB1bmljYXN0IHByZWZpeGVzDQoNCiAgIFlldCB1bmRlZmluZWQgdW5p Y2FzdCBwcmVmaXhlcyBmcm9tIGEgZm9ybWF0IHByZWZpeCBvdGhlciB0aGFu DQogICAyMDAwOjovMyBNVVNUIE5PVCBiZSBhZHZlcnRpc2VkIGJ5IGFueSBy b3V0aW5nIHByb3RvY29sIGluIHRoZSA2Qm9uZS4NCiAgIEluIHBhcnRpY3Vs YXIsIFJGQyAyNDcxIHRlc3QgYWRkcmVzc2VzIE1VU1QgTk9UIGJlIGFkdmVy dGlzZWQgb24gdGhlDQogICA2Qm9uZS4NCg0KICAgUm91dGluZyBvZiBnbG9i YWwgdW5pY2FzdCBwcmVmaXhlcyBvdXRzaWRlIHRoZSA2Qm9uZSByYW5nZQ0K ICAgKDNmZmU6Oi8xNiksIGFuZCByb3V0aW5nIG9mIGdsb2JhbCB1bmljYXN0 IHByZWZpeGVzIHlldCB1bmRlbGVnYXRlZA0KICAgaW4gdGhlIHJhbmdlICgz ZmZlOjovMTYpIGFyZSBkaXNjdXNzZWQgaW4gc2VjdGlvbiA0LCBSb3V0aW5n DQogICBwb2xpY2llcywgYmVsb3cuDQoNCjMuOSBJbnRlci1zaXRlIGxpbmtz DQoNCiAgIEdsb2JhbCBJUHY2IGFkZHJlc3NlcyBtdXN0IGJlIHVzZWQgZm9y IHRoZSBlbmQgcG9pbnRzIG9mIGludGVyLXNpdGUNCiAgIGxpbmtzLiBJbiBw YXJ0aWN1bGFyLCBJUHY0IGNvbXBhdGlibGUgYWRkcmVzc2VzIE1VU1QgTk9U IGJlIHVzZWQgZm9yDQogICB0dW5uZWxzLg0KDQogICBTaXRlcyBNQVkgdXNl IE90aGVyIGFkZHJlc3Npbmcgc2NoZW1lcyBmb3IgSW50ZXItc2l0ZSBsaW5r cywgYnV0DQogICB0aGVzZSBhZGRyZXNzZXMgTVVTVCBOT1QgYmUgYWR2ZXJ0 aXNlZCBpbnRvIHRoZSBJUHY2IGdsb2JhbCByb3V0aW5nDQogICB0YWJsZS4N Cg0KICAgUHJlZml4ZXMgZm9yIGludGVyLXNpdGUgbGlua3MgTVVTVCBOT1Qg YmUgaW5qZWN0ZWQgaW4gdGhlIGdsb2JhbA0KICAgcm91dGluZyB0YWJsZXMu DQoNCjMuMTAgNnRvNCBQcmVmaXhlcw0KDQogICBUaGUgNnRvNCBwcmVmaXgs IG9yIHNvbWUgcG9ydGlvbiB0aGVyZW9mLCBNQVkgYmUgYW5ub3VuY2VkIGJ5 IGFueQ0KICAgcFRMQSB3aGljaCBoYXMgYSBjdXJyZW50IGltcGxlbWVudGF0 aW9uIG9mIDZ0bzQgaW4gdGhlaXIgSVB2Ng0KICAgbmV0d29yay4gIEhvd2V2 ZXIsIGFzIDZ0bzQgaW1wbGVtZW50b3JzIGdhaW4gbW9yZSBvcGVyYXRpb25h bA0KICAgZXhwZXJpZW5jZSwgaXQgTUFZIGJlIG5lY2Vzc2FyeSB0byBjaGFu Z2UgdGhpcyBpbiBzb21lIHdheS4gIEF0IHRoZQ0KICAgdGltZSBvZiB0aGUg d3JpdGluZyBvZiB0aGlzIGRvY3VlbWVudCwgYW55IHBUTEEgTUFZIGFubm91 bmNlIHRoZSA2dG80DQogICBwcmVmaXggaW50byBnbG9iYWwgRUJHUC4gSG93 ZXZlciwgaW4gb3JkZXIgdG8gYW5ub3VuY2UgdGhpcyBibG9jaywNCiAgIHRo ZSBwVExBIE1VU1QgaGF2ZSBhIDZ0bzQgcm91dGVyIGFjdGl2ZSwgc291cmNp bmcgdGhpcyBwcmVmaXgNCiAgIGFubm91bmNlbWVudC4gIFRoZSA2dG80IHBy ZWZpeCBNVVNUIGJlIGFubm91bmNlZCBhcyB0aGUgYWdncmVnYXRlDQogICBw cmVmaXgsIDIwMDI6Oi8xNi4gIFN1Ym5ldHMgb2YgdGhpcyBwcmVmaXggTVVT VCBOT1QgYmUgYW5ub3VuY2VkIA0KICAgaW50byB0aGUgNmJvbmUgYmFja2Jv bmUgcm91dGluZyB0YWJsZSwgYXQgYW55IEVHUCBzZXNzaW9uLg0KDQoNCjMu MTEgQWdncmVnYXRpb24gJiBhZHZlcnRpc2VtZW50IGlzc3Vlcw0KDQogICBS b3V0ZSBhZ2dyZWdhdGlvbiBNVVNUIGJlIHBlcmZvcm1lZCBieSBhbnkgYm9y ZGVyIHJvdXRlciB0YWxraW5nIEVHUA0KICAgd2l0aCBhbnkgb3RoZXIgSVB2 NiBzaXRlcy4gTW9yZS1zcGVjaWZpY3MgTVVTVCBOT1QgYmUgbGVha2VkIGlu dG8gb3INCiAgIGFjcm9zcyB0aGUgSVB2NiA2Qm9uZSBiYWNrYm9uZS4NCg0K NC4gUm91dGluZyBQb2xpY2llcyBmb3IgdGhlIDZib25lDQoNCiAgIExlYWYg c2l0ZXMgb3IgcE5MQXMgTVVTVCBvbmx5IGFkdmVydGlzZSB0byBhbiB1cHN0 cmVhbSBwcm92aWRlciB0aGUNCiAgIHByZWZpeGVzIGFzc2lnbmVkIGJ5IHRo YXQgcHJvdmlkZXIuIEFkdmVydGlzaW5nIGEgcHJlZml4IGFzc2lnbmVkIGJ5 DQogICBhbm90aGVyIHByb3ZpZGVyIHRvIGEgcHJvdmlkZXIgaXMgbm90IGFj Y2VwdGFibGUsIGFuZCBicmVha3MgdGhlDQogICBhZ2dyZWdhdGlvbiBtb2Rl bC4gQSBzaXRlIE1VU1QgTk9UIGFkdmVydGlzZSBhIHByZWZpeCBmcm9tIGFu b3RoZXINCiAgIHByb3ZpZGVyIHRvIGEgcHJvdmlkZXIgYXMgYSB3YXkgYXJv dW5kIHRoZSBtdWx0aS1ob21pbmcgcHJvYmxlbS4NCiAgIEhvd2V2ZXIsIGlu IHRoZSBpbnRlcmVzdCBvZiB0ZXN0aW5nIG5ldyBzb2x1dGlvbnMsIG9uZSBt YXkgYnJlYWsgdGhpcw0KICAgcG9saWN5LCBzbyBsb25nIGFzIEFMTCBhZmZl Y3RlZCBwYXJ0aWVzICBhcmUgYXdhcmUgb2YgdGhpcyB0ZXN0LCBhbmQNCiAg IGFsbCBhZ3JlZSB0byBzdXBwb3J0IHRoaXMgdGVzdGluZy4gIFRoZXNlIHBv bGljeSBicmVha3MgTVVTVCBOT1QNCiAgIGFmZmVjdCB0aGUgNmJvbmUgcm91 dGluZyB0YWJsZSBnbG9iYWxseS4gIE1vcmUgc3BlY2lmaWNhbGx5LCBhbnkg dGVzdA0KICAgaW4gdmlvbGF0aW9uIG9mIHRoZSA2Ym9uZSByb3V0aW5nIHBv bGljeSBtdXN0IGJlIHNjb3BlZCB0byBub3QgaW1wYWN0DQogICBvdGhlciBt ZW1iZXJzIG9mIHRoZSA2Ym9uZS4gIHBUTEFzIG9yIG90aGVyIHNpdGVzIHRo YXQgdmlvbGF0ZSB0aGlzDQogICBydWxlIGFyZSBzdWJqZWN0IHRvIHJldmll dywgYW5kIHBvc3NpYmxlIHJlbW92YWwgb2Ygb25lJ3MgcFRMQSwgb3INCiAg IG90aGVyIGRlbGVnYXRpb24uDQoNCiAgIFRvIGNsYXJpZnksIGlmIG9uZSBo YXMgdHdvIHVwc3RyZWFtIHBOTEEgb3IgcFRMQSBwcm92aWRlcnMsIChBIGFu ZCBCDQogICBmb3IgdGhpcyBleGFtcGxlKSwgb25lIE1VU1Qgb25seSBhbm5v dW5jZSB0aGUgcHJlZml4IGRlbGVnYXRlZCB0byBvbmUNCiAgIGJ5IHByb3Zp ZGVyIEEgdG8gcHJvdmlkZXIgQSwgYW5kIG9uZSBNVVNUIG9ubHkgYW5ub3Vu Y2UgdGhlIHByZWZlaXgNCiAgIGRlbGVnYXRlZCBieSBvbmUgZnJvbSBwcm92 aWRlciBCIHVwc3RyZWFtIHRvIHByb3ZpZGVyIEIuIFRoZXJlIGV4aXN0cw0K ICAgbm8gY2lyY3Vtc3RhbmNlIHdoZXJlIHRoaXMgc2hvdWxkIGJlIHZpb2xh dGVkLCBhcyBpdCBicmVha3MgdGhlDQogICBhZ2dyZWdhdGlvbiBtb2RlbCwg YW5kIGNvdWxkIGdsb2JhbGx5IGFmZmVjdCByb3V0aW5nIGRlY2lzaW9ucyBp Zg0KICAgZG93bnN0cmVhbXMgYXJlIGFibGUgdG8gbGVhayBvdGhlciBwcm92 aWRlcnMnIG1vcmUgc3BlY2lmaWMNCiAgIGRlbGVnYXRpb25zIHVwIHRvIGEg cFRMQS4gQXMgdGhlIE1VTFRJNiB3b3JraW5nIGdyb3VwIHdvcmtzIHRocm91 Z2gNCiAgIG11bHRpLWhvbWluZyBwcm9ibGVtcywgdGhlcmUgbWF5IGJlIGEg bmVlZCB0byBhbHRlciB0aGlzIHJ1bGUNCiAgIHNsaWdodGx5LCB0byB0ZXN0 IG5ldyBzdHJhdGVnaWVzIGZvciBkZXBsb3ltZW50LiBIb3dldmVyLCBpbiB0 aGUgY2FzZQ0KICAgb2YgY3VycmVudCBzcGVjaWZpY2F0aW9ucyBhdCB0aGUg dGltZSBvZiB0aGlzIHdyaXRpbmcsIHRoZXJlIGlzIG5vDQogICByZWFzb24g dG8gYWR2ZXJ0aXNlIG1vcmUgc3BlY2lmaWNzLCBhbmQgcFRMQSdzIE1VU1Qg YWRoZXJlIHRvIHRoZQ0KICAgY3VycmVudCBhZ2dyZWdhdGlvbiBtb2RlbC4g IEFueSBicmVha2FnZSBvZiB0aGlzIHJ1bGUgbXVzdCBiZSBhZ3JlZWQgdG8N CiAgIGJ5IHRoZSBjdXJyZW50IGNoYWlycyBvZiBib3RoIHRoZSBOR1RSQU5T LCBhbmQgTVVMVEk2IHdvcmtpbmcgZ3JvdXBzLA0KICAgYWxvbmcgd2l0aCBh bnkgb3RoZXIgZ292ZXJuaW5nIGJvZHkgb2YgdGhlIDZib25lIGF0IHRoZSB0 aW1lLg0KDQogICBTaXRlIGJvcmRlciByb3V0ZXJzIGZvciBwTkxBIG9yIGxl YWYgc2l0ZXMgU0hPVUxEIGFkdmVydGlzZQ0KICAgb25seSBhZ2dyZWdhdGUg cHJlZml4IGFsbG9jYXRlZCB0byB0aGVtIGJ5IHRoZWlyIHVwc3RyZWFtIHBy b3ZpZGVyLg0KICAgYSBuTkxBIG9yIGxlYWYgc2l0ZSBNQVkgYWR2ZXJ0aXNl LCB2aWEgRUdQLCBtb3JlIHNwZWNpZmljIHJvdXRlcywNCiAgIChmb3IgZXhh bXBsZSwgdG8gYWlkIGluIGxvYWQtc2hhcmluZyBhY3Jvc3MgbXVsdGlwbGUg bGlua3MgdG8gb25lIA0KICAgcHJvdmlkZXIpIGJ1dCB0aGlzIG11c3QgYmUg YWdyZWVkIHVwb24gYnkgdGhlIHVwc3RyZWFtIHByb3ZpZGVyIGFuZCAgDQog ICB0aGUgc2l0ZSBpbiBxdWVzdGlvbi4gIEZ1cnRoZXIsIGl0IGlzIHRoZSBy ZXNwb25zaWJpbGl0eSBvZiB0aGUgDQogICB1cHN0cmVhbSBwcm92aWRlciB0 byBzY29wZSB0aGVzZSBhbm5vdW5jZW1lbnRzIHNvIHRoZXkgZG8gbm90IGVu dGVyDQogICBpbnRvIGFueSBFR1Agc2Vzc2lvbiB0byBhIHBUTEEgb3Igb3Ro ZXIgcGFydHkgd2l0aG91dCBjb25zZW50Lg0KDQogICBBbGwgNmJvbmUgcFRM QXMgTVVTVCBOT1QgYWR2ZXJ0aXNlIHByZWZpeGVzIGxvbmdlciB0aGFuIGEg Z2l2ZW4gcFRMQQ0KICAgZGVsZWdhdGlvbiAoLzI0LCAvMjgsIG9yIC8zMikg dG8gb3RoZXIgNmJvbmUgcFRMQXMgdW5sZXNzIHNwZWNpYWwNCiAgIHBlZXJp bmcgYXJyYW5nZW1lbnRzIGFyZSBpbXBsZW1lbnRlZC4gV2hlbiBzdWNoIHNw ZWNpYWwgcGVlcmluZw0KICAgYWdncmVlbWVudHMgYXJlIGluIHBsYWNlIGJl dHdlZW4gYW55IHR3byBvciBtb3JlIDZib25lIHBUTEFzLCBjYXJlDQogICBN VVNUIGJlIHRha2VuIG5vdCB0byBsZWFrIHRoZSBtb3JlIHNwZWNpZmljcyB0 byBvdGhlciA2Ym9uZSBwVExBcyBub3QNCiAgIHBhcnRpY2lwYXRpbmcgaW4g dGhlIHBlZXJpbmcgYWdncmVlbWVudC4gNmJvbmUgcFRMQXMgd2hpY2ggaGF2 ZSBzdWNoDQogICBhZ3JlZW1lbnRzIGluIHBsYWNlIE1VU1QgTk9UICBhZHZl cnRpc2Ugb3RoZXIgNmJvbmUgcFRMQSBtb3JlDQogICBzcGVjaWZpY3MgdG8g ZG93bnN0cmVhbSA2Ym9uZSBwTkxBcyBvciBsZWFmIHNpdGVzLCBhcyB0aGlz IHdpbGwgYnJlYWsNCiAgIHRoZSBiZXN0LXBhdGggcm91dGluZyBkZWNpc2lv bi4NCg0KICAgVGhlIHBlZXJpbmcgYWdyZWVtZW50cyBhY3Jvc3MgdGhlIDZC b25lIG1heSBiZSBieSBuYXR1cmUgbm9uLQ0KICAgY29tbWVyY2lhbCwgYW5k IHRoZXJlZm9yZSBNQVkgYWxsb3cgdHJhbnNpdCB0cmFmZmljLCBpZiBwZWVy aW5nDQogICBhZ3JlZW1lbnRzIG9mIHRoaXMgbmF0dXJlIGFyZSBtYWRlLiBI b3dldmVyLCBubyBwVExBIGlzIFJFUVVJUkVEIHRvDQogICBnaXZlIG9yIHJl Y2VpdmUgdHJhbnNpdCBzZXJ2aWNlIGZyb20gYW5vdGhlciBwVExBLiAgSG93 ZXZlciwgYmVsb3cgaW4NCiAgIHNlY3Rpb24gMTAsIHJlcXVpcmVtZW50cyBm b3IgYWdncmVnYXRpb24sIGFuZCBndWlkZWxpbmVzIGZvciANCiAgIHR1bm5l bCBlc3RhYmxpc2htZW50IGFyZSBnaXZlbiwgYW5kIE1VU1QgYmUgYWRoZXJl ZCB0byBhY2NvcmRpbmcgdG8NCiAgIHRoZSBydWxlcyBzdGF0ZWQgaW4gc2Vj dGlvbiAxMA0KDQogICBFdmVudHVhbGx5LCB0aGUgSW50ZXJuZXQgcmVnaXN0 cmllcyB3aWxsIGFzc2lnbiBwcmVmaXhlcyB1bmRlciBvdGhlcg0KICAgdGhh biB0aGUgNkJvbmUgVExBICgzRkZFOjovMTYpLiAgUmVnaXN0cnkgYXNzaWdu ZWQgcHJlZml4ZXMgKGN1cnJlbnRseQ0KICAgLzMyJ3Mgd2l0aGluIHRoZSAy MDAxOjovMTYgc3BhY2UpIGFyZSBkZWxlZ2F0ZWQsIGFuZCB0aGVzZSBwcmVm aXhlcyANCiAgIE1BWSBiZSBhbm5vdW5jZWQgYW5kIGNhcnJpZWQgb24gdGhl IDZib25lLg0KDQogICBUaGUgb3JnYW5pemF0aW9ucyByZWNlaXZpbmcgcHJl Zml4ZXMgdW5kZXIgdGhlc2UgbmV3ZXIgVExBcyB3b3VsZCBiZQ0KICAgZXhw ZWN0ZWQgdG8gd2FudCB0byBlc3RhYmxpc2ggcGVlcmluZyBhbmQgY29ubmVj dGl2aXR5IHJlbGF0aW9uc2hpcHMNCiAgIHdpdGggb3RoZXIgSVB2NiBuZXR3 b3JrcywgYm90aCBpbiB0aGUgbmV3ZXIgVExBIHNwYWNlIGFuZCBpbiB0aGUN CiAgIDZib25lIHBUTEEgc3BhY2UuIFBlZXJpbmcgYmV0d2VlbiBuZXcgVExB J3MgYW5kIHRoZSBjdXJyZW50IDZCb25lDQogICBwVExBJ3MgTUFZIG9jY3Vy LCBhbmQgZGV0YWlscyBzdWNoIGFzIHRyYW5zaXQsIGFuZCB3aGF0IHJvdXRl cyBhcmUNCiAgIHJlY2VpdmVkIGJ5IGVhY2gsIGFyZSBvdXRzaWRlIG9mIGdl bmVyYWwgcGVlcmluZyBydWxlcyBhcyBzdGF0ZWQgaW4NCiAgIHRoaXMgbWVt bywgYW5kIGFyZSBsZWZ0IHVwIHRvIHRoZSBtZW1iZXJzIG9mIHRob3NlIFRM QSdzIGFuZCBwVExBJ3MNCiAgIHRoYXQgYXJlIGVzdGFibGlzaGluZyBzYWlk IHBlZXJpbmdzLiBIb3dldmVyLCBpdCBpcyBleHBlY3RlZCB0aGF0DQogICBt b3N0IG9mIHRoZSBydWxlcyBkaXNjdXNzZWQgaGVyZSBhcmUgZXF1YWxseSBh cHBsaWNhYmxlIHRvIG5ldyBUTEFzLg0KDQo1LiBUaGUgNkJvbmUgUmVnaXN0 cnkNCg0KICAgVGhlIDZCb25lIHJlZ2lzdHJ5IGlzIGEgUklQRS0xODEgZGF0 YWJhc2Ugd2l0aCBJUHY2IGV4dGVuc2lvbnMgdXNlZA0KICAgdG8gc3RvcmUg aW5mb3JtYXRpb24gYWJvdXQgdGhlIDZCb25lLCBhbmQgaXRzIHNpdGVzLiBU aGUgNmJvbmUgaXMNCiAgIGFjY2Vzc2libGUgYXQ6DQoNCiAgICAgICAgIDxo dHRwOi8vd3d3LjZib25lLm5ldC93aG9pcy5odG1sPikNCg0KICAgRWFjaCA2 Qm9uZSBzaXRlIE1VU1QgbWFpbnRhaW4gdGhlIHJlbGV2YW50IGVudHJpZXMg aW4gdGhlIDZCb25lDQogICByZWdpc3RyeS4gSW4gcGFydGljdWxhciwgdGhl IGZvbGxvd2luZyBvYmplY3QgTVVTVCBiZSBwcmVzZW50IGZvciBhbGwNCiAg IDZCb25lIGxlYWYgc2l0ZXMsIHBOTEFzIGFuZCBwVExBczoNCg0KICAgLSAg SVB2Ni1zaXRlOiBzaXRlIGRlc2NyaXB0aW9uDQoNCiAgIC0gIEluZXQ2bnVt OiBwcmVmaXggZGVsZWdhdGlvbiAob25lIHJlY29yZCBNVVNUIGV4aXN0IGZv ciBlYWNoDQogICAgICBkZWxlZ2F0aW9uKQ0KDQogICAtICBNbnRuZXI6IGNv bnRhY3QgaW5mbyBmb3Igc2l0ZSBtYWludGFuY2UvYWRtaW5pc3RyYXRpb24g c3RhZmYuDQoNCiAgIE90aGVyIG9iamVjdHMgTUFZIGJlIG1haW50YWluZWQg YXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIHNpdGVzIHN1Y2gNCiAgIGFzIHJv dXRpbmcgcG9saWN5IGRlc2NyaXB0b3JzLCBwZXJzb24sIG9yIHJvbGUgb2Jq ZWN0cy4gIFRoZSBNbnRuZXINCiAgIG9iamVjdCBNVVNUIG1ha2UgcmVmZXJl bmNlIHRvIGEgcm9sZSBvciBwZXJzb24gb2JqZWN0LCBidXQgdGhvc2UgTUFZ DQogICBOT1QgbmVjZXNzYXJpbHkgcmVzaWRlIGluIHRoZSA2Qm9uZSByZWdp c3RyeS4gVGhleSBjYW4gYmUgc3RvcmVkDQogICB3aXRoaW4gYW55IG9mIHRo ZSBJbnRlcm5ldCByZWdpc3RyeSBkYXRhYmFzZXMgKEFSSU4sIEFQTklDLCBS SVBFLU5DQywNCiAgIGV0Yy4pICBUdW5uZWwgZGVzY3JpcHRvcnMgU0hPVUxE IGJlIGVudGVyZWQgaW50byB0aGUgcmVnaXN0cnksIGFuZCANCiAgIGtlcHQg cmVhc29uYWJseSB1cCB0byBkYXRlLg0KDQo2LiBHdWlkZWxpbmVzIGZvciBu ZXcgc2l0ZXMgam9pbmluZyB0aGUgNkJvbmUNCg0KICAgTmV3IHNpdGVzIGpv aW5pbmcgdGhlIDZCb25lIHNob3VsZCBzZWVrIHRvIGNvbm5lY3QgdG8gYSB0 cmFuc2l0IHBOTEENCiAgIG9yIGEgcFRMQSB3aXRoaW4gdGhlaXIgcmVnaW9u LCBhbmQgcHJlZmVyYWJseSBhcyBjbG9zZSBhcyBwb3NzaWJsZSB0bw0KICAg dGhlaXIgZXhpc3RpbmcgSVB2NCBwaHlzaWNhbCBhbmQgcm91dGluZyBwYXRo IGZvciBJbnRlcm5ldCBzZXJ2aWNlLg0KICAgVGhlIDZCb25lIHdlYiBzaXRl IGF0IDxodHRwOi8vd3d3LjZib25lLm5ldD4gaGFzIHZhcmlvdXMgaW5mb3Jt YXRpb24NCiAgIGFuZCB0b29scyB0byBoZWxwIGZpbmQgY2FuZGlkYXRlIDZi b25lIG5ldHdvcmtzLg0KDQogICBBbnkgc2l0ZSBjb25uZWN0ZWQgdG8gdGhl IDZCb25lIE1VU1QgbWFpbnRhaW4gYSBETlMgc2VydmVyIGZvcg0KICAgZm9y d2FyZCBuYW1lIGxvb2t1cHMgYW5kIHJldmVyc2UgYWRkcmVzcyBsb29rdXBz LiAgVGhlIGpvaW5pbmcgc2l0ZQ0KICAgTVVTVCBtYWludGFpbiB0aGUgNkJv bmUgb2JqZWN0cyByZWxhdGl2ZSB0byBpdHMgc2l0ZSwgYXMgZGVzY3JpYmUg aW4NCiAgIHNlY3Rpb24gNS4NCg0KICAgVGhlIHVwc3RyZWFtIHByb3ZpZGVy IE1VU1QgZGVsZWdhdGUgdGhlIHJldmVyc2UgYWRkcmVzcyB0cmFuc2xhdGlv bg0KICAgem9uZSBpbiBETlMgdG8gdGhlIGpvaW5pbmcgc2l0ZSwgb3IgaGF2 ZSBhbiBhZ3JlZW1lbnQgaW4gcGxhY2UgdG8NCiAgIHBlcmZvcm0gcHJpbWFy eSBETlMgZm9yIHRoYXQgZG93bnN0cmVhbS4gVGhlIHByb3ZpZGVyIE1VU1Qg YWxzbw0KICAgY3JlYXRlIHRoZSA2Qm9uZSByZWdpc3RyeSBpbmV0Nm51bSBv YmplY3QgcmVmbGVjdGluZyB0aGUgZGVsZWdhdGVkDQogICBhZGRyZXNzIHNw YWNlLg0KDQogICBVcCB0byBkYXRlIGluZm9ybWF0aW5vIGFib3V0IGhvdyB0 byBqb2luIHRoZSA2Qm9uZSBpcyBhdmFpbGFibGUgb24NCiAgIHRoZSA2Qm9u ZSBXZWIgc2l0ZSBhdCA8aHR0cDovL3d3dy42Ym9uZS5uZXQ+Lg0KDQo3LiBH dWlkZWxpbmVzIGZvciA2Qm9uZSBwVExBIHNpdGVzDQoNCiAgIFRoZSBmb2xs b3dpbmcgcnVsZXMgYXBwbHkgdG8gcXVhbGlmeSBmb3IgYSA2Qm9uZSBwVExB IGFsbG9jYXRpb24uIEl0DQogICBzaG91bGQgYmUgcmVjb2duaXplZCB0aGF0 IGhvbGRlcnMgb2YgNkJvbmUgcFRMQSBhbGxvY2F0aW9ucyBhcmUNCiAgIGV4 cGVjdGVkIHRvIHByb3ZpZGUgcHJvZHVjdGlvbiBxdWFsaXR5IGJhY2tib25l IG5ldHdvcmsgc2VydmljZXMgZm9yDQogICB0aGUgNkJvbmUuDQoNCiAgIDEu IFRoZSBwVExBIEFwcGxpY2FudCBtdXN0IGhhdmUgYSBtaW5pbXVtIG9mIHNp eCAoNikgbW9udGhzIG9mDQogICAgICBxdWFsaWZ5aW5nIGV4cGVyaWVuY2Ug YXMgYSA2Qm9uZSBlbmQtc2l0ZSBvciBwTkxBIHRyYW5zaXQuICBEdXJpbmcN CiAgICAgIHRoZSBlbnRpcmUgcXVhbGlmeWluZyBwZXJpb2QgdGhlIEFwcGxp Y2FudCBtdXN0IGJlIG9wZXJhdGlvbmFsbHkNCiAgICAgIHByb3ZpZGluZyB0 aGUgZm9sbG93aW5nOg0KDQogICAgICBhLiBGdWxseSBtYWludGFpbmVkLCB1 cCB0byBkYXRlLCA2Qm9uZSBSZWdpc3RyeSBlbnRyaWVzIGZvciB0aGVpcg0K ICAgICAgICAgaXB2Ni1zaXRlIGluZXQ2bnVtLCBtbnRuZXIsIGFuZCBwZXJz b24gb2JqZWN0cywgaW5jbHVkaW5nIGVhY2gNCiAgICAgICAgIHR1bm5lbCB0 aGF0IHRoZSBBcHBsaWNhbnQgaGFzLg0KDQogICAgICBiLiBGdWxseSBtYWlu dGFpbmVkLCBhbmQgcmVsaWFibGUsIEJHUDQrIHBlZXJpbmcgYW5kIGNvbm5l Y3Rpdml0eQ0KICAgICAgICAgYmV0d2VlbiB0aGUgQXBwbGljYW50J3MgYm91 bmRhcnkgcm91dGVyIGFuZCB0aGUgYXBwcm9wcmlhdGUNCiAgICAgICAgIGNv bm5lY3Rpb24gcG9pbnQgaW50byB0aGUgNkJvbmUuIFRoaXMgcm91dGVyIG11 c3QgYmUgSVB2Ng0KICAgICAgICAgcGluZ2FibGUuIFRoaXMgY3JpdGVyaWEg aXMganVkZ2VkIGJ5IG1lbWJlcnMgb2YgdGhlIDZCb25lDQogICAgICAgICBP cGVyYXRpb25zIEdyb3VwIGF0IHRoZSB0aW1lIG9mIHRoZSBBcHBsaWNhbnQn cyBwVExBIHJlcXVlc3QuDQoNCiAgICAgIGMuIEZ1bGx5IG1haW50YWluZWQg RE5TIGZvcndhcmQgKEFBQUEpIGFuZCByZXZlcnNlIChpcDYuaW50KQ0KICAg ICAgICAgZW50cmllcyBmb3IgdGhlIEFwcGxpY2FudCdzIHJvdXRlcihzKSBh bmQgYXQgbGVhc3Qgb25lIGhvc3QNCiAgICAgICAgIHN5c3RlbS4NCg0KICAg ICAgZC4gQSBmdWxseSBtYWludGFpbmVkLCBhbmQgcmVsaWFibGUsIElQdjYt YWNjZXNzaWJsZSBzeXN0ZW0NCiAgICAgICAgIHByb3ZpZGluZywgYXQgYSBt aW1pbXVtLCBvbmUgb3IgbW9yZSB3ZWIgcGFnZXMsIGRlc2NyaWJpbmcgdGhl DQogICAgICAgICBBcHBsaWNhbnQncyBJUHY2IHNlcnZpY2VzLiAgVGhpcyBz ZXJ2ZXIgbXVzdCBiZSBJUHY2IHBpbmdhYmxlLg0KDQogICAyLiBUaGUgcFRM QSBBcHBsaWNhbnQgTVVTVCBoYXZlIHRoZSBhYmlsaXR5IGFuZCBpbnRlbnQg dG8gcHJvdmlkZQ0KICAgICAgInByb2R1Y3Rpb24tcXVhbGl0eSIgNkJvbmUg YmFja2JvbmUgc2VydmljZS4gQXBwbGljYW50cyBtdXN0DQogICAgICBwcm92 aWRlIGEgc3RhdGVtZW50IGFuZCBpbmZvcm1hdGlvbiBpbiBzdXBwb3J0IG9m IHRoaXMgY2xhaW0uDQogICAgICBUaGlzIE1VU1QgaW5jbHVkZSB0aGUgZm9s bG93aW5nOg0KDQogICAgICBhLiBBIHN1cHBvcnQgc3RhZmYgb2YgdHdvIHBl cnNvbnMgbWluaW11bSwgdGhyZWUgcHJlZmVyYWJsZSwgd2l0aA0KICAgICAg ICAgcGVyc29uIGF0dHJpYnV0ZXMgcmVnaXN0ZXJlZCBmb3IgZWFjaCBpbiB0 aGUgaXB2Ni1zaXRlIG9iamVjdA0KICAgICAgICAgZm9yIHRoZSBwVExBIGFw cGxpY2FudC4NCg0KICAgICAgYi4gQSBjb21tb24gbWFpbGJveCBmb3Igc3Vw cG9ydCBjb250YWN0IHB1cnBvc2VzIHRoYXQgYWxsIHN1cHBvcnQNCiAgICAg ICAgIHN0YWZmIGhhdmUgYWNlc3MgdG8sIHBvaW50ZWQgdG8gd2l0aCBhIG5v dGlmeSBhdHRyaWJ1dGUgaW4gdGhlDQogICAgICAgICBpcHY2LXNpdGUgb2Jq ZWN0IGZvciB0aGUgcFRMQSBBcHBsaWNhbnQuDQoNCiAgIDMuIFRoZSBwVExB IEFwcGxpY2FudCBNVVNUIGhhdmUgYSBwb3RlbnRpYWwgInVzZXIgY29tbXVu aXR5IiB0aGF0DQogICAgICB3b3VsZCBiZSBzZXJ2ZWQgYnkgaXRzIGJlY29t aW5nIGEgcFRMQSwgZS5nLiwgdGhlIEFwcGxpY2FudCBpcyBhDQogICAgICBt YWpvciBwcm92aWRlciBvZiBJbnRlcm5ldCBzZXJ2aWNlIGluIGEgcmVnaW9u LCBjb3VudHJ5LCBvciBmb2N1cw0KICAgICAgb2YgaW50ZXJlc3QuIEFwcGxp Y2FudCBtdXN0IHByb3ZpZGUgYSBzdGF0ZW1lbnQgYW5kIGluZm9ybWF0aW9u IGluDQogICAgICBzdXBwb3J0IHRoaXMgY2xhaW0uDQoNCldPT1A7IHByb3Bv c2VkIHJlcGxhY2VtZW50IGZvciAjMy4NCiAgIDMuIFRoZSBwVExBIEFwcGxp Y2FudCBNVVNUIGludGVuZCBmbyBwcm92aWRlIElTUC1saWtlIHNlcnZpY2Vz IA0KICAgICAgdGhhdCB3b3VkbCBiZSBzZXJ2ZWQgYnkgaXRzIGJlY29taW5n IGEgcFRMQS4gZS5nLiwgdGhlIEFwcGxpY2FudA0KICAgICAgaXMgYSBtYWpv ciBwcm92aWRlciBvZiBJbnRlcm5ldCBzZXJ2aWNlIGluIGEgcmVnaW9uLiAg QXBwbGljYW50IA0KICAgICAgbXVzdCBwcm92aWRlciBhIHN0YXRlbWVudCBh bmQgaW5mb3JtYXRpb24gaW4gc3VwcG9ydCBvZiB0aGlzIGNsYWltLg0KDQog ICA0LiBUaGUgcFRMQSBBcHBsaWNhbnQgTVVTVCBjb21taXQgdG8gYWJpZGUg YnkgdGhlIGN1cnJlbnQgNkJvbmUNCiAgICAgIG9wZXJhdGlvbmFsIHJ1bGVz IGFuZCBwb2xpY2llcyBhcyB0aGV5IGV4aXN0IGF0IHRpbWUgb2YgaXRzDQog ICAgICBhcHBsaWNhdGlvbiwgYW5kIGFncmVlIHRvIGFiaWRlIGJ5IGZ1dHVy ZSA2Qm9uZSBiYWNrYm9uZQ0KICAgICAgb3BlcmF0aW9uYWwgcnVsZXMgYW5k IHBvbGljaWVzIGFzIHRoZXkgZXZvbHZlIGJ5IGNvbnNlbnN1cyBvZiB0aGUN CiAgICAgIDZCb25lIGJhY2tib25lIGFuZCB1c2VyIGNvbW11bml0eS4gIE5v bi1jb25jdXJlbmNlIHdpdGggY3VycmVudCANCiAgICAgIDZCb25lIGJhY2ti b25lIGFuZCByb3V0aW5nIGd1aWxkZWxpbmVzIE1BWSByZXN1bHQgaW4gdGhl IHJlbW92YWwNCiAgICAgIG9mIG9uZSdzIDZCb25lIHBUTEEgZGVsZWdhdGlv biwgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIDZCb25lDQogICAgICBTdGVl cmluZyBHcm91cA0KICANCiAgIDUuIFRoZSBwVExBIEFwcGxpY2FudCBNVVNU IGhhdmUgYSB2YWxpZCBQdWJsaWMgQXV0b25vbW91cyBTeXN0ZW0NCiAgICAg IE51bWJlci4gIFJlcXVlc3QgZm9yIHBUTEEgdW5kZXIgcHJpdmF0ZSBBdXRv bm9tb3VzIFN5c3RlbSANCiAgICAgIChBU04gNjQ1MTIgdGhydSA2NTUzNSkg bnVtYmVycyB3aWxsIG5vdCBiZSBlbnRlcnRhaW5lZC4NCiAgIA0KICAgNi4g VGhlIHBUTEEgQXBwbGljYW50IE1VU1QsIHVwb24gZGVsZWFnYXRpb24gb2Yg dGhlIHBUTEEsIGVuc3VyZSANCiAgICAgIHRoYXQgQXBwbGljYW50J3MgcFRM QSBpcyBnbG9iYWxseSB2aXNpYmxlIGluIHRoZSA2Qm9uZSBiYWNrYm9uZSwN CiAgICAgIHRocm91Z2ggYXQgbGVhc3QgMiBUcmFuc2l0IGNvbm5lY3Rpb25z LiAgSXQgaXMgYWR2aXNhYmxlIHRoYXQgd2hpbGUNCiAgICAgIHRoZSBwVExB IG93bmVyIG5lZWRzIHRvIG1haW50YWluIGdsb2JhbCByZWFjaGFiaWxpdHkg Zm9yIHRoZSBwVExBLA0KICAgICAgdGhlIG93bmVyIGRvZXMgbm90IG1lc2gg c28gZ3JlYXQgYXMgdG9vIGNhdXNlIGFuIHVuZHVlbHkgbGFyZ2UgDQogICAg ICBudW1iZXIgb2YgaW5lZmZpY2llbnQgcGF0aHMgYXNzb2NpYXRlZCB3aXRo IGluZWZmaWNpZW50IDZCb25lDQogICAgICB0dW5uZWxzIHRoYXQgdmlvbGF0 ZSBjb21tb24gc2Vuc2UgZ3VpbGRlbGluZXMgZm9yIERlbGF5LCBJUHY0DQog ICAgICBob3BzLCBldGMuLi4NCg0KICAgNy4gVGhlIHBUTEEgYXBwbGljYW50 IE1VU1QgYmUgcmVzcG9uc2l2ZSB0byBjb21wbGFpbnRzLCBvciBvcGVyYXRp b25hbA0KICAgICAgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBvbmUncyBwVExB LiAgUHJlZmVyYWJseSwgYSByZXNwb25zZSB3aXRoaW4NCiAgICAgIDI0IGhv dXJzIGlzIGFwcHJlY2lhdGVkLiAgSWYgYSBwVExBIGhvbGRlciBpcyBub24t cmVzcG9uc2l2ZSB0byANCiAgICAgIHJlcGV0aXRpdmUgcmVxdWVzdHMgZm9y IGFzc2lzdGFuY2UsIG9yIGRvZXMgbm90IHJlc29sdmUgYSBwcm9ibGVtIA0K ICAgICAgaW4gYSB0aW1lbHkgZmFzaGlvbiwgdGhlIDZib25lIG1haWxpbmcg bGlzdCBzZXJ2ZXMgYXMgYSBncmVhdCBwbGFjZSANCiAgICAgIHRvIGJyaW5n IHRoZSBpc3N1ZSB0byBhIGdyZWF0ZXIgYXVkaWVuY2UuICBTaG91bGQgYSBw VExBIGNvbnRpbnVhbGx5IA0KICAgICAgdW5yZXNwb25zaXZlIHRvIGlzc3Vl cyBzdXJyb3VuZGluZyB0aGUgYmVoYXZpb3Igb2YgdGhhdCBwVExBLCBzYWlk IHBUTEENCiAgICAgIGhvbGRlciBtYXkgYmUgc3ViamVjdCB0byByZXByZW1h bmQsIHdpdGggdGhlIHBvdGVudGlhbCBvZiByZXZvY2F0aW9uIA0KICAgICAg b2YgdGhhdCBwVExBLCBiYXNlZCBvbiBjb25jZW5zdXMgYnkgdGhlIDZCb25l IFN0ZWVyaW5nIEdyb3VwDQoNCiAgIFdoZW4gYW4gQXBwbGljYW50IHNlZWtz IHRvIHJlY2VpdmUgYSBwVExBIGFsbG9jYXRpb24sIGl0IHdpbGwgYXBwbHkN CiAgIHRvIHRoZSA2Qm9uZSBPcGVyYXRpb25zIEdyb3VwIChzZWUgc2VjdGlv biA4IGJlbG93KSBieSBwcm92aWRpbmcgdG8NCiAgIHRoZSBHcm91cCBpbmZv cm1hdGlvbiBpbiBzdXBwb3J0IG9mIGl0cyBjbGFpbXMgdGhhdCBpdCBtZWV0 cyB0aGUNCiAgIGNyaXRlcmlhIGFib3ZlLg0KDQo4LiA2Qm9uZSBPcGVyYXRp b25zIEdyb3VwDQoNCiAgIFRoZSA2Qm9uZSBPcGVyYXRpb25zIEdyb3VwIGlz IHRoZSBncm91cCBpbiBjaGFyZ2Ugb2YgbW9uaXRvcmluZyBhbmQNCiAgIHBv bGljaW5nIGFkaGVyZW5jZSB0byB0aGUgY3VycmVudCBydWxlcy4gTWVtYmVy c2hpcCBpbiB0aGUgNkJvbmUNCiAgIE9wZXJhdGlvbnMgR3JvdXAgaXMgbWFu ZGF0b3J5IGZvciwgYW5kIHJlc3RyaWN0ZWQgdG8sIHNpdGVzIGNvbm5lY3Rl ZA0KICAgdG8gdGhlIDZCb25lLg0KDQogICBUaGUgNkJvbmUgT3BlcmF0aW9u cyBHcm91cCBpcyBjdXJyZW50bHkgZGVmaW5lZCBieSB0aG9zZSBtZW1iZXJz IG9mDQogICB0aGUgZXhpc3RpbmcgNkJvbmUgbWFpbGluZyBsaXN0IHdobyBy ZXByZXNlbnQgc2l0ZXMgcGFydGljaXBhdGluZyBpbg0KICAgdGhlIDZCb25l LiBUaGVyZWZvcmUgaXQgaXMgaW5jdW1iZW50IG9uIHJlbGV2YW50IHNpdGUg Y29udGFjdHMgdG8NCiAgIGpvaW4gdGhlIDZCb25lIG1haWxpbmcgbGlzdC4g SW5zdHJ1Y3Rpb25zIG9uIGhvdyB0byBqb2luIHRoZSBsaXN0IGFyZQ0KICAg bWFpbnRhaW5lZCBvbiB0aGUgNkJvbmUgd2ViIHNpdGUgYXQgPCBodHRwOi8v d3d3LjZib25lLm5ldD4uDQogICANCiAgIDEuIDZCb25lIFN0ZWVyaW5nIEdy b3VwDQogICAgICBBIDZCb25lIFN0ZWVyaW5nIEdyb3VwLCBhIHN0YW5kaW5n IGdyb3VwIGZvcm1lZCBieSBjb25zZW5zdXMgb2YgDQogICAgICB0aGUgNmJv bmUgT3BlcmF0aW9ucyBHcm91cCwgd2lsbCBjb25mZXIgYW5kIGRlY2lkZSBv biBpc3N1ZXMgdGhhdA0KICAgICAgbmVlZCB0byByZWFjaCByZXNvbHV0aW9u IHRoYXQgYXJlIG5vdCByZWFjaGluZyBjb25zZW5zdXMgb2YgdGhlDQogICAg ICA2Qm9uZSBPcGVyYXRpb25zIEdyb3VwLg0KICAgICANCjkuICBDb21tb24g cnVsZXMgZW5mb3JjZW1lbnQgZm9yIHRoZSA2Ym9uZQ0KDQogICBQYXJ0aWNp cGF0aW9uIGluIHRoZSA2Qm9uZSBpcyBhIHZvbHVudGFyeSBhbmQgYmVuZXZv bGVudCB1bmRlcnRha2luZy4NCiAgIEhvd2V2ZXIsIHBhcnRpY2lwYXRpbmcg c2l0ZXMgYXJlIGV4cGVjdGVkIHRvIGFkaGVyZSB0byB0aGUgcnVsZXMgYW5k DQogICBwb2xpY2llcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBpbiBv cmRlciB0byBtYWludGFpbiB0aGUgNkJvbmUgYXMNCiAgIGEgcXVhbGl0eSB0 b29sIGZvciB0aGUgZGVwbG95bWVudCBvZiwgYW5kIHRyYW5zaXRpb24gdG8s IElQdjYNCiAgIHByb3RvY29scyBhbmQgdGhlIHByb2R1Y3RzIGltcGxlbWVu dGluZyB0aGVtLg0KDQogICBUaGUgZm9sbG93aW5nIGlzIGluIHN1cHBvcnQg b2YgcG9saWNpbmcgYWRoZXJlbmNlIHRvIDZCb25lIHJ1bGVzIGFuZA0KICAg cG9saWNpZXM6DQoNCiAgIDEuIEVhY2ggcFRMQSBzaXRlIGhhcyBjb21taXR0 ZWQgdG8gaW1wbGVtZW50IHRoZSA2Qm9uZSdzIHJ1bGVzIGFuZA0KICAgICAg cG9saWNpZXMsIGFuZCBNVVNUIHRyeSB0byBlbnN1cmUgdGhleSBhcmUgYWRo ZXJlZCB0byBieSBzaXRlcw0KICAgICAgd2l0aGluIHRoZWlyIGFkbWluaXN0 cmF0aXZlIGNvbnRyb2wsIGkuZS4gdGhvc2UgdG8gd2hvIHByZWZpeGVzDQog ICAgICB1bmRlciB0aGVpciByZXNwZWN0aXZlIHBUTEEgcHJlZml4IGhhdmUg YmVlbiBkZWxlZ2F0ZWQuDQoNCiAgIDIuIFdoZW4gYSBzaXRlIGRldGVjdHMg YW4gaXNzdWUsIGl0IFNIT1VMRCBmaXJzdCB1c2UgdGhlIDZCb25lDQogICAg ICByZWdpc3RyeSB0byBjb250YWN0IHRoZSBzaXRlIG1haW50YWluZXIgYW5k IHdvcmsgdGhlIGlzc3VlLg0KDQogICAzLiBJZiBub3RoaW5nIGhhcHBlbnMs IG9yIHRoZXJlIGlzIGRpc2FncmVlbWVudCBvbiB3aGF0IHRoZSByaWdodA0K ICAgICAgc29sdXRpb24gaXMsIHRoZSBpc3N1ZSBTSE9VTEQgYmUgYnJvdWdo dCB0byB0aGUgNkJvbmUgT3BlcmF0aW9ucw0KICAgICAgR3JvdXAuDQoNCiAg IDQuIFdoZW4gdGhlIHByb2JsZW0gaXMgcmVsYXRlZCB0byBhIHByb2R1Y3Qg aXNzdWUsIHRoZSBzaXRlKHMpDQogICAgICBpbnZvbHZlZCBTSE9VTEQgYmUg cmVzcG9uc2libGUgZm9yIGNvbnRhY3RpbmcgdGhlIHByb2R1Y3QgdmVuZG9y DQogICAgICBhbmQgd29yayB0b3dhcmQgaXRzIHJlc29sdXRpb24uDQoNCiAg IDUuIFdoZW4gYW4gaXNzdWUgY2F1c2VzIG1ham9yIG9wZXJhdGlvbmFsIHBy b2JsZW1zLCBiYWNrYm9uZSBzaXRlcw0KICAgICAgU0hPVUxEIGRlY2lkZSB0 byB0ZW1wb3JhcmlseSBzZXQgZmlsdGVycyBpbiBvcmRlciB0byByZXN0b3Jl DQogICAgICBzZXJ2aWNlLg0KDQoNCg0KDQoNCg0KDQoNCg0KV09PUDogTkVX IEZJTFRFUklORyBTRUNUSU9OOg0KDQoxMC4gIEZpbHRlcmluZyBvbiB0aGUg NkJvbmU7IEd1aWRlbGluZXMuDQogICAxLiBwVExBIGZpbHRlcmluZyByZXF1 aXJlbWVudHMuDQogICAgICBwVExBJ3MgbXVzdCBmaWx0ZXIgb3RoZXIgcFRM QSBwcmVmaXhlcyBhY2NvcmRpbmdseSwgZm9sbG93aW5nIA0KICAgICAgdGhl IGFnZ3JlZ2F0aW9uIG1vZGVsIHN0YXRlZCBpbiBzZWN0aW9uIDQuICBUbyBk YXRlLCA2Ym9uZSANCiAgICAgIGRlbGVnYXRpb25zIGhhdmUgY29tZSBpbiB0 aHJlZSBwaGFzZXMuDQoNCiAgICAgIC0zRkZFOjAwMDA6Oi8yNCB0aHJ1IDNG RkU6MzkwMDo6LzI0IGRlbGVnYXRlZCBhcyAvMjQncyB0byBwVExBDQoNCiAg ICAgIC0zRkZFOjgwMDA6Oi8yNCB0aHJ1IDNGRkU6ODNGMDo6LzI0IGRlbGVn YXRlZCBhcyAvMjgncyB0byBwVExBDQoNCiAgICAgIC0zRkZFOjQwMDA6Oi8z MiB0aHJ1IDNGRkU6N0ZGRjo6LzMyIGRlbGVnYXRlZCBhcyAvMzIncyB0byBw VExBDQoNCiAgICAgIEEgcFRMQSB3aG8gZW5nYWdlcyBpbiBwZWVyaW5nIHdp dGggb3RoZXIgcFRMQSBtZW1iZXJzIChhcyBpcyBhIA0KICAgICAgcmVxdWly ZW1lbnQgZm9yIHBUTEEgZGVsZWdhdGlvbnMgaW4gdGhlIGZpcnN0IHBsYWNl KSBNVVNUIGZpbHRlcg0KICAgICAgYW5ub3VuY2VtZW50cyBoZWFyZCBmcm9t IG90aGVyIHBUTEEncyBib3RoIHRvIGFuZCBmcm9tIHRoZXNlIHBlZXJzLg0K ICAgICAgTGVha2luZyBvZiBwcmVmaXhlcyBsb25nZXIgdGhhbiB0aGUgYWJv dmUsIHdpdGhvdXQgYXBwcm9wcmlhdGUNCiAgICAgIGZpeGVzIHVwb24gbm90 aWZpY2F0aW9uLCBpcyBncm91bmRzIGZvciByZW1vdmFsIG9mIG9uZSdzIHBU TEEgDQogICAgICBzdGF0dXMuICBUaGUgNkJvbmUgU3RlZXJpbmcgR3JvdXAg d2lsbCBhY3QgYXMgdGhlIGZpbmFsIA0KICAgICAgYXV0aG9yaXR5IG9uIHN1 Y2ggYWN0aW9ucy4NCg0KICAgICAgQWRkaXRpb25hbGx5LCBwVExBJ3MgbXVz dCBmaWx0ZXIgYXBwcm9wcmlhdGVseSB0byBvbmUncyBkb3duc3RyZWFtDQog ICAgICBjdXN0b21lcnMvaW50ZXJjb25uZWN0cy4gIGEgcFRMQSBNVVNUIGFj Y2VwdCBPTkxZIHRoZSBwcmVmaXgoZXMpIA0KICAgICAgZnJvbSBhIGRvd25z dHJlYW0gdGhhdCB3ZXJlIGRlbGVnYXRlZCB0byB0aGF0IGRvd25zdHJlYW0g YnkgdGhlIHBUTEENCiAgICAgIFN1Ym5ldHMgb3IgQWdncmVnYXRlcyByZWNl aXZlZCBmcm9tIGEgZG93bnN0cmVhbSwgZnJvbSBhbm90aGVyIA0KICAgICAg cFRMQSdzIDZCb25lIHNwYWNlIE1VU1QgTk9UIGJlIGFjY2VwdGVkIGJ5IHRo ZSBwVExBIGluIHF1ZXN0aW9uLiANCiAgICAgIFRoaXMgcG90ZW50aWFsbHkg Y291bGQgY2F1c2Ugc3ViLW9wdGltYWwgZm9yd2FyZGluZyBkZWNpc2lvbnMg d2l0aGluDQogICAgICB0aGUgNmJvbmUsIHNvIHRoaXMgTVVTVCBiZSBhdm9p ZGVkLiAgUmVmdXNhbCB0byBjb21wbHkgd2l0aCB0aGlzDQogICAgICBydWxl IGlzIHN1YmplY3QgdG8gcmV2aWV3IGJ5IHRoZSA2Qm9uZSBTdGVlcmluZyBH cm91cCwgYW5kIE1BWSANCiAgICAgIHJlc3VsdCBpbiByZW1vdmFsIG9mIG9u ZSdzIHBUTEEgc3RhdHVzLg0KDQpIRUxQOiBGaW5pc2ggdGhpcyBzZWN0aW9u Lg0KDQoNCg0KMTEuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBU aGUgcmVzdWx0IG9mIGluY29ycmVjdCBlbnRyaWVzIGluIHJvdXRpbmcgdGFi bGVzIGlzIHVzdWFsbHkNCiAgIHVucmVhY2hhYmxlIHNpdGVzLiAgSGF2aW5n IGd1aWRlbGluZXMgdG8gYWdncmVnYXRlIG9yIHJlamVjdCByb3V0ZXMNCiAg IHdpbGwgY2xlYW4gdXAgdGhlIHJvdXRpbmcgdGFibGVzLiBJdCBpcyBleHBl Y3RlZCB0aGF0IHVzaW5nIHRoZXNlDQogICBydWxlcyBhbmQgcG9saWNpZXMs IHJvdXRpbmcgb24gdGhlIDZCb25lIHdpbGwgYmUgbGVzcyBzZW5zaXRpdmUg dG8NCiAgIGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFja3MgZHVlIHRvIG1pc2xl YWRpbmcgcm91dGVzLg0KDQogICBUaGUgNkJvbmUgaXMgYW4gSVB2NiB0ZXN0 YmVkIHRvIGFzc2lzdCBpbiB0aGUgZXZvbHV0aW9uIGFuZA0KICAgZGVwbG95 bWVudCBvZiBJUHY2LiBUaGVyZWZvcmUsIGRlbmlhbCBvZiBzZXJ2aWNlIG9y IHBhY2tldCBkaXNjbG9zdXJlDQogICBhcmUgdG8gYmUgZXhwZWN0ZWQuICBI b3dldmVyLCBpdCBpcyB0aGUgcFRMQSBmcm9tIHdoZXJlIHRoZSBhdHRhY2sN CiAgIG9yaWdpbmF0ZWQgd2hvIGhhcyB1bHRpbWF0ZSByZXNwb25zaWJpbGl0 eSBmb3IgaXNvbGF0aW5nIGFuZCBmaXhpbmcNCiAgIHByb2JsZW1zIG9mIHRo aXMgbmF0dXJlLiBJdCBpcyBhbHNvIGV2ZXJ5IDZCb25lIHNpdGUncyByZXNw b25zaWJpbGl0eQ0KICAgdG8gc2FmZWx5IGludHJvZHVjZSBuZXcgdGVzdCBz eXN0ZW1zIGludG8gdGhlIDZCb25lLCBieSBwbGFjaW5nIHRoZW0NCiAgIGF0 IGEgc3RyYXRlZ2ljYWxseSBzYWZlIHBsYWNlcyB3aGljaCB3aWxsIGhhdmUg bWluaW1hbCBpbXBhY3Qgb24NCiAgIG90aGVyIDZCb25lIHNpdGVzLCBzaG91 bGQgYnVncyBvciBtaXNjb25maWd1cmF0aW9ucyBvY2N1ci4NCg0KMTIuIFJl ZmVyZW5jZXMNCg0KICAgW1JGQyAyMzczXSBIaW5kZW4sIFIuIGFuZCBTLiBE ZWVyaW5nLCAiSVAgVmVyc2lvbiA2IEFkZHJlc3NpbmcNCiAgICAgICAgICAg ICAgQXJjaGl0ZWN0dXJlIiwgUkZDIDIzNzMsIEp1bHkgMTk5OC4NCg0KICAg W1JGQyAyNDcxXSBIaW5kZW4sIFIuLCBGaW5rLCBSLiBhbmQgSi4gUG9zdGVs LCAiSVB2NiBUZXN0aW5nIEFkZHJlc3MNCiAgICAgICAgICAgICAgQWxsb2Nh dGlvbiIsIFJGQyAyNDcxLCBEZWNlbWJlciAxOTk4Lg0KDQogICBbUkZDIDI1 NDZdIER1cmFuZCwgQS4gYW5kIEIuIEJ1Y2xpbiwgIjZCb25lIFJvdXRpbmcg UHJhY3RpY2UiLCBSRkMNCiAgICAgICAgICAgICAgMjU0NiwgTWFyY2ggMTk5 OQ0KDQogICBbUkZDIDIwODBdIE1hbGtpbiwgRy4gYW5kIFIuIE1pbm5lYXIs ICJSSVBuZyBmb3IgSVB2NiIsIFJGQyAyMDgwLA0KICAgICAgICAgICAgICBK YW51YXJ5IDE5OTcuDQoNCiAgIFtSRkMgMjExOV0gQnJhZG5lciwgUy4sICJL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAg ICAgICAgIFJlcXVpcmVtZW50ICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5 LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDIDIyODNdIEJhdGVzLCBULiwgQ2hh bmRyYSwgUi4sIEthdHosIEQuIGFuZCBZLiBSZWtodGVyLA0KICAgICAgICAg ICAgICAiTXVsdGlwcm90b2NvbCBFeHRlbnNpb25zIGZvciBCR1AtNCIsIFJG QyAyMjgzLCBNYXJjaA0KICAgICAgICAgICAgICAxOTk4Lg0KDQogICBbUklQ RS0xODFdIEJhdGVzLCBULiwgR2VyaWNoLCBFLiwgSm9uY2hlcmF5LCBMLiwg Sm91YW5pZ290LCBKLiwNCiAgICAgICAgICAgICAgS2FycmVuYmVyZywgRC4s IFRlcnBzdHJhLCBNLiBhbmQgSi4gIFl1LCAgUmVwcmVzZW50YXRpb24NCiAg ICAgICAgICAgICAgb2YgSVAgUm91dGluZyBQb2xpY2llcyBpbiBhIFJvdXRp bmcgUmVnaXN0cnkuICBUZWNobmljYWwNCiAgICAgICAgICAgICAgUmVwb3J0 IHJpcGUtMTgxLCBSSVBFLCBSSVBFIE5DQywgQW1zdGVyZGFtLCBOZXRoZXJs YW5kcywNCiAgICAgICAgICAgICAgT2N0b2JlciAxOTk0Lg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoxMy4gQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIFJvYiBS b2NrZWxsDQogICBFTWFpbDogcnJvY2tlbGxAc3ByaW50Lm5ldA0KDQoNCiAg IEJvYiBGaW5rDQogICBFTWFpbDogZmlua0Blcy5uZXQNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K ---559023410-1483920592-1037224748=:516-- From nicolas.deffayet@ndsoftware.net Sun Nov 17 14:57:38 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 17 Nov 2002 15:57:38 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> On Sun, 2002-11-17 at 13:57, Robert Kiessling wrote: > What matters is what actually happens, i.e. what is *likely* to cause > problems. And here we saw several instances of unmaintained and badly > responsive 6bone site, and sites running two-year old copies of > depricated BGP software. There are badly responsive sTLA too. A lot of ISP don't maintain their sTLA because they have too many work with their IPv4 network. > For example, all of the LIRs I have spoken to understand the problem > with long-distance tunnels and are getting rid of them, while at the > same time a 6bone site proudly announced to have more than 90 tunnels. You can have a short-distance tunnel with a lot of packet loss... We are open for native peering, but many ISP don't want establish native peering with us because we don't have a sTLA. 6bone can have more native peering if this ISP are more open. > > sTLA owner can don't have IPv6 experience because it's not a > > requierement for get a sTLA. > > Entities operating RIR allocations will have BGP experience, which is > more relevent. And they have a view and sense of real network > topology. Yes, but i mean _IPv6 experience_. > > I think that your solution is not good and will kill the 6bone. > > It might be more productive if you explained concretely why you think > it's a bad idea. I don't see any indication why this would "kill > 6bone". What do you mean by this? Why your solution is not good: - If you cut 6bone and RIR, 6bone will have a very bad routing (i know, it's not a problem for you because you have a sTLA). - Many pTLA offer a real production quality service, why limit them ? - A pTLA can offer better service than a sTLA. - IPv6 world must have the same routing policy, why complicate IPv6 routing ? => Do a clean of 6bone and be more strict on RFC2772 is better. Your solution will kill the 6bone because the 6bone will be too limited, and all ISP will resquest a sTLA for do their tests. > In other words, you operate it as a hobby, while LIRs operate > professionally. And it's not just you, it's many other 6bone sites > too. We don't operate our pTLA as a hobby. We operate our pTLA professionally. We have a 24x7 contact and we reply within 24 hours. We provide to ours users a production quality service and we have a good routing (we use filtering, MED,...). A lot of sTLA don't operate their sTLA professionally. A lot of sTLA don't have a 24x7 contact and don't reply within 24 hours. A lot of sTLA don't have a good routing (they don't use filtering, MED,...) Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From jeroen@unfix.org Sun Nov 17 15:57:57 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Sun, 17 Nov 2002 16:57:57 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <002a01c28e52$1953f3f0$210d640a@unfix.org> Nicolas DEFFAYET wrote: Short pre-hand pre/conclusion.... RFC2772 all depends on DEFFAYET, I mean NDSOFTWARE baffling away yet again. I am really wondering how the other employees of his company think about all this. Mike CHENEY, Myriam MOREL, Bruno NASH, Chris BURTON where are you?? > On Sun, 2002-11-17 at 13:57, Robert Kiessling wrote: > > > For example, all of the LIRs I have spoken to understand the problem > > with long-distance tunnels and are getting rid of them, while at the > > same time a 6bone site proudly announced to have more than > 90 tunnels. > > You can have a short-distance tunnel with a lot of packet loss... > > We are open for native peering, but many ISP don't want > establish native > peering with us because we don't have a sTLA. > 6bone can have more native peering if this ISP are more open. On which _real_ IX (check http://www.v6nap.net/) is "NDSOFTWARE" present? Maybe you can go there and people would be pleased to setup a native peering. > > > sTLA owner can don't have IPv6 experience because it's not a > > > requierement for get a sTLA. > > > > Entities operating RIR allocations will have BGP > experience, which is > > more relevent. And they have a view and sense of real network > > topology. > > Yes, but i mean _IPv6 experience_. You really need BGP experience to make BGP work. As for routing IPv6 is only playing with bigger addresses, nothing more. > > > I think that your solution is not good and will kill the 6bone. > > > > It might be more productive if you explained concretely why > you think > > it's a bad idea. I don't see any indication why this would "kill > > 6bone". What do you mean by this? > > Why your solution is not good: > > - If you cut 6bone and RIR, 6bone will have a very bad routing (i know, > it's not a problem for you because you have a sTLA). They will get better routing as it will be pushed to the edges and those "not so responsive pTLA's" as you call it (read your own words below) won't do any transit routing any more for most sites. All traffic will be carried over productional links. And as productional links do have an SLA (that's Service Level Agreement) there is money (penalties and pay) behind it too keep it up and working. This is just like the situation in the current IPv4 world. No pay/pain, no gain. > - Many pTLA offer a real production quality service, why limit them ? If they offer production services they should move to RIR space as 6bone space was meant for _testing_ and _experimental_ purposes. > - A pTLA can offer better service than a sTLA. Now you really have to explain everybody why that is. Or do you mean the english word "can" is a possibility like: "I can jump over a mountain" doesn't how high the mountain is. > - IPv6 world must have the same routing policy, why complicate IPv6 > routing ? The same as which? As IPv4? Where people inject /30's into the DFZ? There was another reason for making IPv6 and limiting on TLA sizes: smaller global routing tables. Or at least the hope of keeping it in limits so you don't have to buy a new router with 1TB of memory. > => Do a clean of 6bone and be more strict on RFC2772 is better. > Your solution will kill the 6bone because the 6bone will be > too limited, and all ISP will resquest a sTLA for do their tests. Real ISP's can get sTLA's, they pay for it and have a customer base and other ISP's who they need to keep friends with otherwise they will get cut off or loose their paying customers. > > In other words, you operate it as a hobby, while LIRs operate > > professionally. And it's not just you, it's many other 6bone sites > > too. > > We don't operate our pTLA as a hobby. > We operate our pTLA professionally. > We have a 24x7 contact and we reply within 24 hours. Which of the one is it, or do you mean there is a contact who is alive but actually can't be reached? You might start writing in french as that is probably a better way to express yourself. > We provide to ours users a production quality service and we And do you also act like that to the rest of the world ? It's not a local problem mind you, not only "oh they don't pay me so I can break it". > have a good routing (we use filtering, MED,...). > > A lot of sTLA don't operate their sTLA professionally. > A lot of sTLA don't have a 24x7 contact and don't reply > within 24 hours. > A lot of sTLA don't have a good routing (they don't use filtering, > MED,...) Yeah yeah you pasted that before, do you realize it stands for Multi Exit Descriminator? But how can you use it if you only have 1 exit or have you got your own native IPv6 cables between your routers? Greets, Jeroen From rico@noris.net Sun Nov 17 16:01:41 2002 From: rico@noris.net (Rico Gloeckner) Date: Sun, 17 Nov 2002 17:01:41 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Sun, Nov 17, 2002 at 03:57:38PM +0100 References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021117170141.J5615@noris.de> On Sun, Nov 17, 2002 at 03:57:38PM +0100, Nicolas DEFFAYET wrote: > On Sun, 2002-11-17 at 13:57, Robert Kiessling wrote: > > Entities operating RIR allocations will have BGP experience, which is > > more relevent. And they have a view and sense of real network > > topology. > > Yes, but i mean _IPv6 experience_. Networks with Production-Quality will probably have more Experience, even if it is lacking IPv6-Experience. > Why your solution is not good: > > - If you cut 6bone and RIR, 6bone will have a very bad routing (i know, > it's not a problem for you because you have a sTLA). Nonsense. Its about keeping 6bone Sites off the DFZ to reduce Bad Effects within the DFZ. > - A pTLA can offer better service than a sTLA. Oh? Can i have an Explanation for that? > - IPv6 world must have the same routing policy, why complicate IPv6 > routing ? > > => Do a clean of 6bone and be more strict on RFC2772 is better. Well, IMHO it would be good to: - put sTLAs in the DFZ and let them provide Production Quality - put pTLAs outside the DFZ and let them provide a TestingBed so they can actually /test/ without harming the DFZ. > Your solution will kill the 6bone because the 6bone will be too limited, > and all ISP will resquest a sTLA for do their tests. No. It will bring any Space to its Purpose, see above. For any EndCustomer it gets less and less difficult to receive RIR-Space. > We don't operate our pTLA as a hobby. > We operate our pTLA professionally. > We have a 24x7 contact and we reply within 24 hours. > We provide to ours users a production quality service and we have a good > routing (we use filtering, MED,...). > > A lot of sTLA don't operate their sTLA professionally. > A lot of sTLA don't have a 24x7 contact and don't reply within 24 hours. > A lot of sTLA don't have a good routing (they don't use filtering, > MED,...) It doesnt effect Facts if you keep repeating yourself. I'd personally consider it a rather... childish Behaviour. -rg From Robert.Kiessling@de.easynet.net Sun Nov 17 16:30:29 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 17 Nov 2002 16:30:29 +0000 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> Message-ID: Nicolas DEFFAYET writes: > Why your solution is not good: > > - If you cut 6bone and RIR, 6bone will have a very bad routing (i know, > it's not a problem for you because you have a sTLA). You are not seriously suggesting that current 6bone routing is anywhere near optimal, are you? > - Many pTLA offer a real production quality service, why limit them ? They can continue to offer their service, and most of them can get RIR space. Please refer to my original email to see some of the problems which are tackled by this proposal. > - A pTLA can offer better service than a sTLA. I don't argue on the base of "can", whatever you mean by this. I argue on the base of facts such as past incidents and the reluctance of ISPs to offer IPv6 access to existing IPv4 services, caused by bad IPv6 network performance. > - IPv6 world must have the same routing policy, why complicate IPv6 > routing ? And all people must be equal. > Your solution will kill the 6bone because the 6bone will be too limited, > and all ISP will resquest a sTLA for do their tests. So be it. What's bad about it? As Bob said, 6bone is for the people who cannot get RIR space. Robert From berni@birkenwald.de Sun Nov 17 16:54:40 2002 From: berni@birkenwald.de (Bernhard Schmidt) Date: Sun, 17 Nov 2002 17:54:40 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021117165440.GA1543@thor.birkenwald.de> On Sun, Nov 17, 2002 at 03:57:38PM +0100, Nicolas DEFFAYET wrote: > We are open for native peering, but many ISP don't want establish native > peering with us because we don't have a sTLA. _Where_ are you open for native peerings, and _where_ do ISPs not want to establish native peerings just because you only have a pTLA? Let me guess, at FNIX6 with the only member being you (one colocated switch in a housing-center, right?)? I would rather blow all my computers to hell than paying colocation fees and a suitable backbone pipe to a housing-center just to be at a wanna-be exchange point. There are enough IPv6 exchange points all over the world right now (oh sorry, I forgot, most have an IPv4 network too so they are no IPv6 exchange points at all). Or wait, you're talking about native peering in general, not about native peering at exchange points. So, could you provide an interface for a T3 or STM-1 at your "routers" to do native IPv6 peering on the line? Get real, kid. Most people don't care about you having a sTLA or a pTLA, they care about you being Nicolas DEFFAYET and the way you got your pTLA and your ASN. -- bye bye Bernhard From nicolas.deffayet@ndsoftware.net Sun Nov 17 17:18:22 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 17 Nov 2002 18:18:22 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <1037553502.635.6125.camel@wks1.fr.corp.ndsoftware.com> On Sun, 2002-11-17 at 17:30, Robert Kiessling wrote: > I don't argue on the base of "can", whatever you mean by this. I argue > on the base of facts such as past incidents and the reluctance of ISPs > to offer IPv6 access to existing IPv4 services, caused by bad IPv6 > network performance. You can have good performances and guarantee the transit only when the most part of IPv6 Internet will be native. I'm sorry, but cut 6bone and RIR is not the good solution. The solution for have a better IPv6 network is have only native peering. Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From nicolas.deffayet@ndsoftware.net Sun Nov 17 17:53:26 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 17 Nov 2002 18:53:26 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <20021117165440.GA1543@thor.birkenwald.de> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> <20021117165440.GA1543@thor.birkenwald.de> Message-ID: <1037555605.637.6232.camel@wks1.fr.corp.ndsoftware.com> On Sun, 2002-11-17 at 17:54, Bernhard Schmidt wrote: > Or wait, you're talking about native peering in general, not about > native peering at exchange points. So, could you provide an interface > for a T3 or STM-1 at your "routers" to do native IPv6 peering on the > line? Currently we peer only on FastEthernet. -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From berni@birkenwald.de Sun Nov 17 18:04:42 2002 From: berni@birkenwald.de (Bernhard Schmidt) Date: Sun, 17 Nov 2002 19:04:42 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037555605.637.6232.camel@wks1.fr.corp.ndsoftware.com> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> <20021117165440.GA1543@thor.birkenwald.de> <1037555605.637.6232.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021117180442.GA9431@thor.birkenwald.de> On Sun, Nov 17, 2002 at 06:53:26PM +0100, Nicolas DEFFAYET wrote: > Currently we peer only on FastEthernet. at FNIX6 with yourself? -- bye bye Bernhard From nicolas.deffayet@ndsoftware.net Sun Nov 17 18:13:22 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 17 Nov 2002 19:13:22 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <20021117180442.GA9431@thor.birkenwald.de> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> <20021117165440.GA1543@thor.birkenwald.de> <1037555605.637.6232.camel@wks1.fr.corp.ndsoftware.com> <20021117180442.GA9431@thor.birkenwald.de> Message-ID: <1037556802.611.6294.camel@wks1.fr.corp.ndsoftware.com> On Sun, 2002-11-17 at 19:04, Bernhard Schmidt wrote: > On Sun, Nov 17, 2002 at 06:53:26PM +0100, Nicolas DEFFAYET wrote: > > > Currently we peer only on FastEthernet. > > at FNIX6 with yourself? mv troll /dev/null Thanks -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From berni@birkenwald.de Sun Nov 17 18:20:39 2002 From: berni@birkenwald.de (Bernhard Schmidt) Date: Sun, 17 Nov 2002 19:20:39 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037556802.611.6294.camel@wks1.fr.corp.ndsoftware.com> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> <20021117165440.GA1543@thor.birkenwald.de> <1037555605.637.6232.camel@wks1.fr.corp.ndsoftware.com> <20021117180442.GA9431@thor.birkenwald.de> <1037556802.611.6294.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021117182039.GA9949@thor.birkenwald.de> On Sun, Nov 17, 2002 at 07:13:22PM +0100, Nicolas DEFFAYET wrote: > > > Currently we peer only on FastEthernet. > > at FNIX6 with yourself? > mv troll /dev/null That was a very simple question above, please just answer "yes" or "no". BTW: "mv: troll: No such file or directory". Must be something available on your side only :-) EOD from my side, it's more than useless. You won't get the point in the next decades. -- bye bye Bernhard From nicolas.deffayet@ndsoftware.net Sun Nov 17 19:08:39 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 17 Nov 2002 20:08:39 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <002a01c28e52$1953f3f0$210d640a@unfix.org> References: <002a01c28e52$1953f3f0$210d640a@unfix.org> Message-ID: <1037560118.635.6461.camel@wks1.fr.corp.ndsoftware.com> On Sun, 2002-11-17 at 16:57, Jeroen Massar wrote: > > On which _real_ IX (check http://www.v6nap.net/) is "NDSOFTWARE" > present? > Maybe you can go there and people would be pleased to setup a native > peering. mv troll /dev/null I have sent an email (09 Oct 2002 00:50:52 +0200) to Marc Blanchet for update the list of http://www.v6nap.net, but i don't get news. The list is not updated, there is a lot of other IX who have an IPv6 support... > > - Many pTLA offer a real production quality service, why limit them ? > > If they offer production services they should move to RIR space as 6bone > space was meant for _testing_ and _experimental_ purposes. production quality service != production service > > - IPv6 world must have the same routing policy, why complicate IPv6 > > routing ? > > The same as which? As IPv4? Where people inject /30's into the DFZ? > There was another reason for making IPv6 and limiting on TLA sizes: > smaller global routing tables. > Or at least the hope of keeping it in limits so you don't have to buy > a new router with 1TB of memory. I mean: pTLA and sTLA (IPv6 world) must have the same routing policy. I don't talk about IPv4. > > have a good routing (we use filtering, MED,...). > > > > A lot of sTLA don't operate their sTLA professionally. > > A lot of sTLA don't have a 24x7 contact and don't reply > > within 24 hours. > > A lot of sTLA don't have a good routing (they don't use filtering, > > MED,...) > > Yeah yeah you pasted that before, do you realize it stands for Multi > Exit Descriminator? > But how can you use it if you only have 1 exit or have you got your own > native IPv6 cables > between your routers? Learn how BGP work. If you have many peers, you have many exit. Network Next Hop Metric LocPrf Weight Path * 2001:200::/35 3ffe:8270:0:1::30 500 0 20834 513 3425 2500 i * 3ffe:4013:f:2a::2 502 0 3292 109 4554 2500 i * 2001:768:e:9::1 510 0 8379 3561 5511 2500 i * 3ffe:4013:f:d::2 540 0 17715 4725 2500 i * 3ffe:4013:f:31::2 520 0 12731 5539 4554 2500 i * 3ffe:4013:f:28::2 520 0 20794 6830 4554 2500 i * 2001:7b0:1ff::c 520 0 15671 8627 790 3549 2500 i * 3ffe:4005:0:1::2e 500 0 24765 1752 5511 2500 i * 2001:7a8:1:f004::1 500 0 13193 3549 2500 i *> 2001:7f8:2:c01d::2 500 0 1752 5511 2500 i * 3ffe:2200:0:8012::1 520 0 2607 6939 2516 2500 i * 3ffe:4013:f:a::2 520 0 15589 6939 2497 2500 i * 3ffe:8340::1:6 510 0 13129 1752 5511 2500 i * 3ffe:4013:f:29::2 500 0 8921 13193 3549 2500 i * 3ffe:4013:f:b::2 530 0 9112 4554 2500 i * 3ffe:400c:feed::2 530 0 13110 4554 2500 i * 3ffe:4013:f:27::2 520 0 8472 6830 4554 2500 i BGP choose the route(s) with shorter ASpath and lower MED. Network Next Hop Metric LocPrf Weight Path * 2001:7a8:1:f004::1 500 0 13193 3549 2500 i *> 2001:7f8:2:c01d::2 500 0 1752 5511 2500 i If there is many routes with the same ASpath size, BGP choose the route will the lower ASN. Network Next Hop Metric LocPrf Weight Path *> 2001:7f8:2:c01d::2 500 0 1752 5511 2500 i Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From tjc@ecs.soton.ac.uk Sun Nov 17 19:54:10 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Sun, 17 Nov 2002 19:54:10 +0000 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037553502.635.6125.camel@wks1.fr.corp.ndsoftware.com> References: <5.1.0.14.0.20021114185901.03697690@imap2.es.net> <1037492705.628.3866.camel@wks1.fr.corp.ndsoftware.com> <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> <1037553502.635.6125.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021117195410.GA19768@login.ecs.soton.ac.uk> On Sun, Nov 17, 2002 at 06:18:22PM +0100, Nicolas DEFFAYET wrote: > On Sun, 2002-11-17 at 17:30, Robert Kiessling wrote: > > > I don't argue on the base of "can", whatever you mean by this. I argue > > on the base of facts such as past incidents and the reluctance of ISPs > > to offer IPv6 access to existing IPv4 services, caused by bad IPv6 > > network performance. > > You can have good performances and guarantee the transit only when the > most part of IPv6 Internet will be native. > > I'm sorry, but cut 6bone and RIR is not the good solution. > > The solution for have a better IPv6 network is have only native peering. I don't think nativeness is the key issue (it is nice though). The key issue is open (and bad) transit... see Pekka's 6bone-mess draft. Tim From tjc@ecs.soton.ac.uk Sun Nov 17 20:44:47 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Sun, 17 Nov 2002 20:44:47 +0000 Subject: [6bone] 6bone-mess-01.txt In-Reply-To: References: Message-ID: <20021117204447.GA20267@login.ecs.soton.ac.uk> > Comments, please. > > (Anyone with more than 5 peers with transit should feel the sting of guilt > now. :-) Some comments on -01.txt. I think the dcoument as is makes the point well. All we need are some agreed answers :) I notice for example that from the IETF here my IPv6 RTT to home (UK) is 400ms, as opposed to 100ms via IPv4. (This is not a US-Europe thing per se as the Abilene-Europe link has near identical RTT due to use of dual-stack links following a very similar path, and no "errant" tunnels) - Comments: Currently, IPv6 Internet is, globally considered, inseparable from the 6bone network. The 6bone has been built as a tighly meshed tunneled topology. As the number of participants has grown, it has become an untangible mess, hindering the real deployment of IPv6 due to low quality of connections. This memo discusses the nature and - The key problem is that many users wish to use IPv6 for daily, production - use, and this is not possible due to the way 6bone prefixes are advertised - and transit is too often given. - We should also point out now that SubTLAs are easier to get in the 2001: - space, we risk the 6boneisation of the so-called "production" IPv6 space. - We could also argue that there is less genuine demand for 6bone pTLAs; indeed - new SubTLA owners no longer require 6bone experience as a precondition for - that allocation(?) 1. Introduction Currently, IPv6 Internet is, globally considered, inseparable from the 6bone network. The 6bone has been built as a tighly meshed tunneled topology. As the number of participants has grown, it has become an untangible mess, hindering the real deployment of IPv6 due to low quality of connections. - I think "low quality" doesn't perhaps state the problem strongly enough. - perhaps mention the lack of stability and predictablity, hampering the use - of IPv6 by *any* users, whether on a 6bone or production prefix site, on - a day-to-day basis. This memo tries to outline some ways to gain better connectivity for the future IPv6 Internet. This can be done by increasing the quality of 6bone (in some applicable parts) and moving the 6bone network to - Indeed applying the principles that make the current IPv4 Internet usable - on a day-to-day basis. It should be noted that as addressing and routing are quite independent, the same problems also exist, in addition to 6bone- allocated pTLA's, with RIR-allocated "sTLA" addresses too. It can often be assumed, though, that those organizations are at least slightly more knowledgeable and serious than an average pTLA holder, due to the process it takes to get an sTLA if you're not an equivalent of Local Internet Registry (LIR). Nevertheless, these are considered as one category. - Yes, the slacker SubTLA rules now make this a concern. This is the root cause why 6bone network is a mess: as there is no hierarchy, most sites try to gain good connectivity by creating tighter mesh to other pTLA/sTLA's: increase the number of virtual peers by creating tunnels. - And in many cases these tunnels are not optimal, instead often spanning - a large number of IPv4 hops, with some pTLA owners collecting peerings as - if they were "trophies". You might expect a typical pTLA to have 5-10 - peerings, in many cases pTLAs have many times this, coupled with lack of - controls on transit. Using IPv6-in-IPv4 tunneling is also not so bad in itself, if used properly; for example, tunneling over resilient IPv4 connectivity within one AS could be seen as highly advantageous to using dedicatede circuits for IPv6 under some circumstances. However, the problem is that tunneling hides the natural, underlying topology: a link may actually consist of many hops, going through many different administrative and technical entities. As such, it becomes very difficult to debug and notice the real problems when using "long" tunnels. Tunneling can also be used to gain connectivity in the absence of native IPv6; as long as one does not provide transit through such "long tunnels", you can only shoot yourself in the foot. - Indeed, it is the transit that causes the problem. Full transit, especially in conjunction with points above is the worst problem: there are no longer useful metrics to choose best paths (as AS-path length, the most imporant global metric in BGP path selection, becomes next to useless), and the network topology gets extremely complicated and unstable. Some metric can naturally be assigned locally, with usually significant effort, but these are indeed often only locally useful. - Witness the resulting mess of paths that cross the atlantic two or even four - times between sites on the same continent. 4. Coping with the Administrative Problems Some of the problems are more of an administrative nature. It is clearly visible that under current pTLA assignment policy [6BROUTING], there are many organizations which are not significant- enough ISP's, transits or such but are still getting pTLA's. This is a double-edged sword: in the absence of IPv6 support by their upstreams, it could be argued it's good that at least someone will do something about IPv6 (note, extending this argument, they should also provide the same services as their ISP would -- ie. not only reap the benefits but also take up the responsibilities); on the other hand, these organizations usually have neither skills, equipment nor customers to understand the operational aspects of being part of a world-wide network, and are the ones worst burdening the 6bone. - I think the number of providers is now growing in most regions to the extent - that this is not the case in the same way as it was 2-3 years ago. Therefore, as one step, the requirements for a pTLA should be made stricter by revising [6BROUTING]; the revised edition should also take more stance on what kind of organization would be eligible for an allocation (a difficult thing to define precisely, to be sure). - Agreed 100%, and this is now happening as a result of a recent pTLA case. Another thing to consider would be whether pTLA allocations could be revoked from "irresponsible" operators (even more difficult thing to define as before), possibly as a consequence to not conforming to possible new guidelines for pTLA's. This might eliminate some specific problematic operators, but it might be that then the focus would just shift to the others; in general, removing existing allocations is a very harsh measure and it is unprobable that it could be done except for special reasons. - There should be some way for pTLAs to be reviewed or revoked. But in theory - filters could also be applied - someone has to offer connectivity for the - "rogues" to be a problem; the "blockade" method you describe below is also - interesting for this. 5. Coping with the Connectivity Problems There are a few main approaches to the connectivity problems described above: 1. Wait until a significant number of transit providers support IPv6 and only try to get anything stable then - I think the path being pursued by the research networks (academic) is to - look at policies, inparticular through use of community tagging, to establish - a stable intrastructure between those networks (in Europe, the US and beyond). - That stability is a prerequisite to using IPv6 applications (e.g. international - conferencing) with confidence that the applications will run as desired. Also, this leads to waiting. As it is, IPv6 connections around the world are, generally speaking, very poor. It is irresponsible to turn on IPv6 by default on e.g. operating systems, as that would only lead to a lower quality for the user: for example, if a website is IPv4/6 dual-stack, trying to use IPv6 by default is often much slower, and should be avoided until the network is in a reasonably good shape. - Well, it's deeper than that, if people go dual stack on web servers, and - advertise AAAA's, and the browsers (as is I think universally the default) - try AAAA's before A's, there will be delays for users where the IPv6 - connectivity is broken. As you say, turning on IPv6 on the "clients" is - currently a "brave" step for site administrators, and only likely to cause - pain. 5.2. Adjust BGP Path Selection or Route Visibility Some might even suggest BGP specification modifications (e.g. taking a lower layer end-to-end latency into account), but those are definitely considered out of scope: only operational measures are discussed. - Some level of network monitoring can give clues to at least perhaps tune - general BGP/filter policies. Indeed most 6bone-related problems are only - spotted by user traceroutes in practice right now. MED is next to useless in itself: with "always-compare-med" -like option, it can be used to influence the path from between two routes of equally long AS-path -- but the path length was deemed a next-to- useless metric in 6bone, so this might only help if AS-paths are very short, e.g. 1 or 2 AS's. - I suppose that the IPv6 BGP would like to know the number of hops in the - underlying IPv4 tunnel, if a plain hop metric is being used, as a 2-hop - AS path may indeed pass through many more IPv4 AS's due to tunnels. 5.2.1. Example of Route Visibility Control In addition to the implemented example of 6NET communities, see below, one could sketch additional ones, like often used in IPv4. Some possibilities are show below. - 6NET is introduced rather suddenly here? (Note that there are several vendor-specific problems with no-export communities, see Appendix A for more information.) There are many possibilities; these are indeed just examples. It is not the purpose of this memo to try to standardize (requiring IANA action) "well- known" communities; but either to give ideas what could be implemented in a non-global scope, e.g. regionally or locally, or come up with simple "if you don't know what to do, you can do this" -rules. - Well, common meaning of the values would be nice, to be able to look at - other policies and understand them more readily. But I think that is as - "standardised" as much as DSCP 8 is standardised for Scavenger/LBE. It should also be noted that this kind of fine-grained policing could prove to be very useful in traditional 6bone routing context -- but that is what we try to escape: simplicity is very rarely gained by adding more complexity. - True. 6.1. Guidelines for End-sites End-sites, usually obtaining a /48 assignment, do not really need to do much, as their possibilities in affecting 6bone routing are, by design, limited (common prefix filters do not allow them to advertise their specific routes). - Assuming those filters are in place! Many sites use 6bone and SubTLA - space combined to try out multihoming, which is one reason why "Old" pTLAs - don't get handed back. The most important things for the end-sites are to: 1. Ask their local ISP(s), both marketing and technical people, for IPv6 if they do not yet provide service: ISP(s) will not usually react unless there is an observed demand, and this will help in making production networks closer to reality. - NOte that tunnel brokers and 6to4 can reduce this demand, as users and sites - can connect and not knock on their admin or upstream ISP door, so long as - Protocol 41 is allowed. 3. Due to designed restrictions regarding advertising more specific routes, usually obtaining two connections doesn't really help much and may cause problems if the ISP(s) implement ingress filtering. It's better to just use one for simplicity unless there are special reasons to do otherwise. - Multihoming experiments? Therefore the benefit (for the whole Internet) of having such an organization establish peering relations with others all over the world, just for itself and the customers, is small. These kinds of organizations must seek transit providers to create hierarchy: when there is enough hierarchy, the branch can be considered globally significant. The most natural action would be to find these from the IPv4 upstreams, but that may not always be possible. If not, as above, it's always good to try to underline that IPv6 transit service is something that's needed. There are some organizations in the community which are often willing to perform transit free of charge, though, too. - Agreed 100% - this single recommendation is perhaps key. 2. Disbanding especially "long tunnels", in particular if these include providing transit. If they cannot be removed, some extra measures like AS-path prepending (outlined in sections above) should be implemented. - Some spring to mind, but best left unnamed here :) 6.3. Guidelines for Transit sTLA/pTLA's "Real" transit-providing organizations should consider whether they could provide limited transit to other organizations too, at least initially. For example, research organizations could be able to provide research-to-commercial and commercial-to-research transit for others too, but fully commercial might be unacceptable due to higher- level policies. - Yes, this may be a bit of a mire. But it is very hard for anyone to offer - commercial IPv6 services with the current 6bone-ness situation. To re-iterate, especially when providing transit for others, care must be observed so that it is done in a controlled fashion. Transit networks are in the key position when applying and forcing proper policies on 6bone: working together, they might be able for force some of the more "irresponsible" pTLA/sTA's to act in a more sensible manner: together they might have much more power in the arm-wrestling match against the 6bone routing mess. - The second key recommendation, I think. The scheme can be extended to other networks too: to add proper certain communities and preferences to routes learned through other networks (like commercial transits, other research networks, etc.) and that way the benefits of good, native connections can be more widely realized. Perhaps then commercial pTLA's/sTLA's would need a lot smaller number of tunnels and transit services (at least to research organizations). - This is happening at the moment, bringing in other academic/research networks - such as Abilene. Something similar could be done in other networks too. The key is to build something that prefers local (hopefully native, but short tunnels are also okay) connections and disallows any uncontrolled transit. - Key recommendation #3 :) So, the role should change from addressing and routing to only (or mainly) addressing. A good question is where these stub/non-transiting sites/pTLA's would get transit from -- who would offer them that. There must be solution for this if this path is to be adopted. One solution would be getting that from one of their ISP's (or their ISPs' upstreams), or secondarily, from some willing third parties. In some cases this may not be possible though. Ideas for the ways to proceed would be appreciated. - I think that sites that already have IPv4 transit need to look for IPv6 transit - from the same supplier. This is easier in the research network case, where - for example in 6NET the universities go to their NRENs, who in turn will look - to 6NET (or GEANT) for transit, or who will have existing peering agreements - with international links (e.g. to the USA). I don't see that IPv6 would demand - any different structure to the connectivity - do we really foresee that new - carriers will emerge for IPv6 traffic, or that (much more likely) existing - carriers will offer (dual-stack) IPv6? tim From RJorgensen@upctechnology.com Sun Nov 17 20:51:25 2002 From: RJorgensen@upctechnology.com (Jorgensen, Roger) Date: Sun, 17 Nov 2002 21:51:25 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals Message-ID: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C52E@nlcbbms03> (someone might be offended by I'm sick of this threat now...) > On Sun, 2002-11-17 at 16:57, Jeroen Massar wrote: > > > > On which _real_ IX (check http://www.v6nap.net/) is "NDSOFTWARE" > > present? > > Maybe you can go there and people would be pleased to setup a native > > peering. > > mv troll /dev/null IF this is how you handle critic I suggest you really stop mailing now.I'm getting sick of your very unproductive respons to everything. You have shown MANY times that you do not have any clue about how REAL network work, REAL as in real routing hardware and real links, NOT tunnels and a few BSD/linux boxes with zebra or whatever you use. Please stop this now. And let's ALL move back to RFC 2772 discussion. > I have sent an email (09 Oct 2002 00:50:52 +0200) to Marc Blanchet for > update the list of http://www.v6nap.net, but i don't get > news. The list > is not updated, there is a lot of other IX who have an IPv6 > support... > > > > > - Many pTLA offer a real production quality service, why > limit them ? > > > > If they offer production services they should move to RIR > space as 6bone > > space was meant for _testing_ and _experimental_ purposes. > > production quality service != production service > > > > - IPv6 world must have the same routing policy, why > complicate IPv6 > > > routing ? > > > > The same as which? As IPv4? Where people inject /30's into the DFZ? > > There was another reason for making IPv6 and limiting on TLA sizes: > > smaller global routing tables. > > Or at least the hope of keeping it in limits so you don't > have to buy > > a new router with 1TB of memory. > > I mean: pTLA and sTLA (IPv6 world) must have the same routing policy. > > I don't talk about IPv4. > > > > have a good routing (we use filtering, MED,...). > > > > > > A lot of sTLA don't operate their sTLA professionally. > > > A lot of sTLA don't have a 24x7 contact and don't reply > > > within 24 hours. > > > A lot of sTLA don't have a good routing (they don't use filtering, > > > MED,...) > > > > Yeah yeah you pasted that before, do you realize it stands for Multi > > Exit Descriminator? > > But how can you use it if you only have 1 exit or have you > got your own > > native IPv6 cables > > between your routers? > > Learn how BGP work. > If you have many peers, you have many exit. > > > > Network Next Hop Metric LocPrf Weight Path > * 2001:200::/35 3ffe:8270:0:1::30 > 500 0 20834 513 > 3425 2500 i > * 3ffe:4013:f:2a::2 > 502 0 3292 109 > 4554 2500 i > * 2001:768:e:9::1 510 0 8379 3561 > 5511 2500 i > * 3ffe:4013:f:d::2 > 540 0 > 17715 4725 > 2500 i > * 3ffe:4013:f:31::2 > 520 0 > 12731 5539 > 4554 2500 i > * 3ffe:4013:f:28::2 > 520 0 > 20794 6830 > 4554 2500 i > * 2001:7b0:1ff::c 520 0 > 15671 8627 > 790 3549 2500 i > * 3ffe:4005:0:1::2e > 500 0 > 24765 1752 > 5511 2500 i > * 2001:7a8:1:f004::1 > 500 0 > 13193 3549 > 2500 i > *> 2001:7f8:2:c01d::2 > 500 0 1752 5511 > 2500 i > * 3ffe:2200:0:8012::1 > 520 0 2607 6939 > 2516 2500 i > * 3ffe:4013:f:a::2 > 520 0 > 15589 6939 > 2497 2500 i > * 3ffe:8340::1:6 510 0 > 13129 1752 > 5511 2500 i > * 3ffe:4013:f:29::2 > 500 0 > 8921 13193 > 3549 2500 i > * 3ffe:4013:f:b::2 > 530 0 9112 4554 > 2500 i > * 3ffe:400c:feed::2 > 530 0 > 13110 4554 > 2500 i > * 3ffe:4013:f:27::2 > 520 0 8472 6830 > 4554 2500 i > > > BGP choose the route(s) with shorter ASpath and lower MED. > > Network Next Hop Metric LocPrf Weight Path > * 2001:7a8:1:f004::1 > 500 0 > 13193 3549 > 2500 i > *> 2001:7f8:2:c01d::2 > 500 0 1752 5511 > 2500 i > > If there is many routes with the same ASpath size, BGP choose > the route > will the lower ASN. > > Network Next Hop Metric LocPrf Weight Path > *> 2001:7f8:2:c01d::2 > 500 0 1752 5511 > 2500 i > > > Best Regards, > > -- > Nicolas DEFFAYET, NDSoftware > NOC Website: http://noc.ndsoftwarenet.com/ > FNIX6: http://www.fnix6.net/ > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > begin 600 winmail.dat M>)\^(@D4`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<` M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.````T@<+`!$` M%0`S`!D```!6`0$@@`,`#@```-('"P`1`!4`.``'````20$!"8`!`"$```!! M-#DT.4$S-T-",#$U-C0X.$)"-S)".3,U.#4X-C$U.``$!P$$@`$`,@```%)% M.B!;-F)O;F5=(%)&0S(W-S(@`5!`0,!]_\*@`*D`^0'$P*`#_,`4`16/PA5![(1)0Y1 M`P$"`&-HX0K``2!T:`0`"Q^!&"!A!4!N;W`E&"(!=Q^@21/0(%\@`6Q?'L!8'QS@$]`%D!]`';!T<#H(+R]W M*&`N=C9N"&%P+AU0="\I(`$?L2).1%-/1E2@5T%212(E&'`8(%L4$`(P/R48 M)$!Y'>%YR0A@(&,#D6=O'X$$D'<=8`!P'H!P'3`+4!U@=WT(8&P>@1U@+?$D M4!YQ=',M`!01=7`C("!`("!I''9E*ED)X`40;FL.\VT"W@'7`+<&PQ,2#$(%+_'M(VL`)`,3$?!RQQ!<`P,/YR M'K`B0"KP!'`:T#`2-S'\'S.9(3X61W"L`M9";R/22) M.#%K,`?@D$)31"\X,75X'=`<;W@'D0/P M'Y`@>F7\8G(OT`6Q)H`@(#QR):7=+')U%!`]'PJ`4"[3-Z2?'Y,@4A#`+9$N M`'0G$+'N3$+@!&`[D6(`T!]`+T'H4D9#(G`W`1!4`"$'(AAOTOH&1*H2T23J`$``5`'V%W)_\I`2)@8D'P M*5!`86Z>)P5`.5$EIQU0=W-.4+Y46'4AADWS!4!7]&0B8/\M)!^Q+]`7L%C3 M)-`M,2="[R:`+0!`Y1[`4"B@):1!)!V#>!E(F`F@/\>L"&&.#`=@`5` M+2$>\"MI]6CH21]R91ZP9-1EJ6;5/Q_":G$^T2Y23U-/\DE2[V$8"K!G($0B M-@;@'5!HZ/]N1$6@!"`'@`!P5R,FT`ZP[S;0,3$G,"V"7P[`+<`%$/<'@`(P M)Q)P"'`[\!007##',7YEKV:W("$]:O]G(/]BWV/C8--#,6S22[!`Q5ABGR1P M!X!$USOP.#!C>6=,_06@;0M0#>!8(F#28UI$YK]HWR5R7&)Z4T0Q)H,_$,#K M!"!@T32`\%P3Z!$R`&1+@!S2"'A?V41!4`NTFAC-/$MP!]2:_T)X'`YDFA11&%H(P0@ M'0"_0"5;`B&&><0M`%J`>7ZH'R_1!]%$XA*!2:,Q5$)_'U('@`1@.L!S7S9@ M<&(ZZV1T+8)S9)(H>,@I0'E__WJ.DV\V8%KD$Z1)'4=G,K9R&&3"`0 M!*$U`D+\1U!##5#][?HI_ZX108._0XX$S_]S_ M[2_N/]=8X&#P#_I_^X__\S_K*0'0XJ"IX.!0SSCV'_OW+]^I8L[A#S#-L#9` M_%_O\__BX.OPXG`V4&`AAN*@/]QA_Z!4@/_?![_7)3`U_<[4,C!'"E\+;]'_ M`^^FP?_@0,WP(P!5D.,?!O\!+^`PSF'@8,U@''`P-."Q">^?%&\5?PT?ZTCO MT#DS!E.O['_,M!//W]9FX&`R`L#_S5#FSQU?'F\67]-3#Q(/P[<8WQ"_^`LR MS8)50#C-4+\<`!-/)B\G/P-/TW(V_G#W;L`88!C),6$`(?\K_]]*?Q=N-_%,+_=-/TY/UW8W3^]: M#UL?,1__XD/L,?Z_5?W'?L*R@-"LX.>>$8.2D=,HT&#)=89A M=[]UAI)`B;"#@V/$8Q!.9%__96]F?V>/:)]RWW/O=/^+3_^,7W@O>3]Z3U]? M8&6_`+;0>%)E9\(PM4"O-XK6+7HM@U=.AJ"88+*PMN!%0$9&05E%5)[03CQ$ M4ZN`O^#",`G73D]:0X'=YK0P"YF;FEX-IA`AG![F6>*UE^`$(0 M`0```#@````\,3`S-S4V,#$Q."XV,S4N-C0V,2YC86UE;$!W:W,Q+F9R+F-O M`#%``0````L```!22D]21T5.4T5.```#`!I``````!X`,$`!````"P`` M`%)*3U)'14Y314X```,`&4```````P#]/^0$```#`"8```````,`-@`````` M`P"`$/____\"`4<``0```#(```!C/553.V$](#MP/4-(14Q,3SML/4Y,0T)" M35,P,RTP,C$Q,3`/@_`0```!$```!*;W)G M96YS96XL(%)O9V5R`````!X`.$`!````"P```%)*3U)'14Y314X```(!^S\! M````3P````````#`#E``0````L```!22D]2 M1T5.4T5.``!````#T``0````4```!2 M13H@`````!X`'0X!````+@```%LV8F]N95T@4D9#,C As an example of efficiency. From the IETF site if I trace to a UK v6 server I am seeing 4x the RTT. If I trace to a US site, I see 3x the RTT. Of course I'm grateful for IPv6 at the IETF, but these sort of comparisons are often typical when trying to use IPv6 for day-to-day work. In that respect it is good that IPv4 and IPv6 RTT from the UK to Abilene sites is pretty much identical. e.g. IETF to news server at U.Oregon (the multi-stream I2 LSR holder... >tracert6 hammer.ipv6.uoregon.edu Tracing route to hammer.ipv6.uoregon.edu [2001:468:d01:dc::80df:dc1d] from 2001:240:5ff:0:68bf:1296:a4a9:a1a0 over a maximum of 30 hops: 1 3 ms 2 ms 3 ms rtr1.ietf55.ops.ietf.org [2001:240:5ff::1] 2 25 ms 26 ms 26 ms 2001:240:5ff:ffff::1 3 206 ms 209 ms 207 ms otm6-bb0.IIJ.Net [2001:240:100:fffc::ff] 4 207 ms 206 ms 206 ms otm6-gate0.IIJ.Net [2001:240:100::204] 5 207 ms 207 ms 208 ms hitachi1.otemachi.wide.ad.jp [2001:200:0:1800 ::9c4:2] 6 207 ms 207 ms 208 ms pc6.otemachi.wide.ad.jp [2001:200:0:1800::9c4 :0] 7 208 ms 208 ms 207 ms pc1.notemachi.wide.ad.jp [2001:200:0:6c01:290 :27ff:fe3a:d8] 8 346 ms 346 ms 346 ms c12k.sanjose.wide.ad.jp [2001:200:0:6c01:209: 11ff:fedb:19fe] 9 293 ms 295 ms 295 ms 2001:200:0:6c04::2 10 308 ms 307 ms 309 ms 2001:468:ff:b4d::2 11 308 ms 311 ms 309 ms 2001:468:d3f:1::2 12 308 ms 307 ms 307 ms hammer.ipv6.uoregon.edu [2001:468:d01:dc::80d f:dc1d] Trace complete. [compared to 100ms IPv4 RTT] Then a trace to a UK server: C:\Documents and Settings\Tim Chown>tracert6 www.ipv6.ac.uk Tracing route to seven.ecs.soton.ac.uk [2001:630:d0:200:a00:20ff:feb5:ef1e] from 2001:240:5ff:0:68bf:1296:a4a9:a1a0 over a maximum of 30 hops: 1 3 ms 3 ms 2 ms rtr1.ietf55.ops.ietf.org [2001:240:5ff::1] 2 25 ms 26 ms 25 ms 2001:240:5ff:ffff::1 3 26 ms 26 ms 26 ms 2001:458:26:2::500 4 54 ms 54 ms 54 ms 3ffe:81d0:ffff:1::4 5 104 ms 106 ms 104 ms fe-tu3.fmt.ipv6.he.net [3ffe:81d0:ffff:1::] 6 375 ms 442 ms 376 ms ulcc.ipv6.ja.net [2001:630:0:1::2e] 7 382 ms 382 ms 383 ms soton.tun.ipv6.ja.net [2001:630:0:1::1e] 8 383 ms 382 ms 382 ms 2001:630:d0:200:a00:20ff:feb5:ef1e Trace complete. [in comparison IPv4 RTT is again around 100ms] tim From itojun@iijlab.net Sun Nov 17 21:10:03 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Mon, 18 Nov 2002 06:10:03 +0900 Subject: [6bone] 6bone-mess-01.txt In-Reply-To: tjc's message of Sun, 17 Nov 2002 20:44:47 GMT. <20021117204447.GA20267@login.ecs.soton.ac.uk> Message-ID: <20021117211003.AB9924B25@coconut.itojun.org> >Some comments on -01.txt. I think the dcoument as is makes the point well. >All we need are some agreed answers :) I notice for example that from the >IETF here my IPv6 RTT to home (UK) is 400ms, as opposed to 100ms via IPv4. part of the reason is because we IIJ (providing IPv6 connectivity this time) have policy not to peer over tunnels, to keep quality of our IPv6 routes/paths. so we have no direct reachability to Europe. the cause of issue is a bit different from 6bone-mess document. >(This is not a US-Europe thing per se as the Abilene-Europe link has near >identical RTT due to use of dual-stack links following a very similar path, >and no "errant" tunnels) IIJ would like to peer with Abilene or any other ASes, of course, if they participate to any of the exchanges we are present. we are present at: PAIX palo alto 6TAP palo alto (L3 IX so there should be no config needed) NYIIX 6IIX-NY and in japan: NSPIXP6 NSPIXP2 JPNAP6 itojun From tjc@ecs.soton.ac.uk Sun Nov 17 21:25:25 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Sun, 17 Nov 2002 21:25:25 +0000 Subject: [6bone] IETF IPv6 connectivity In-Reply-To: <20021117211003.AB9924B25@coconut.itojun.org> References: <20021117204447.GA20267@login.ecs.soton.ac.uk> <20021117211003.AB9924B25@coconut.itojun.org> Message-ID: <20021117212525.GH20267@login.ecs.soton.ac.uk> On Mon, Nov 18, 2002 at 06:10:03AM +0900, itojun@iijlab.net wrote: > >Some comments on -01.txt. I think the dcoument as is makes the point well. > >All we need are some agreed answers :) I notice for example that from the > >IETF here my IPv6 RTT to home (UK) is 400ms, as opposed to 100ms via IPv4. > > part of the reason is because we IIJ (providing IPv6 connectivity > this time) have policy not to peer over tunnels, to keep quality of > our IPv6 routes/paths. so we have no direct reachability to Europe. > the cause of issue is a bit different from 6bone-mess document. It's a tradeoff between a short, good quality tunnel (e.g. to peer with Abilene) and a long native route (i.e. going via Japan to get from one part of the US to another). In this case, the "native only" policy isn't the best choice, although I respect your goal in the longer-term view. > >(This is not a US-Europe thing per se as the Abilene-Europe link has near > >identical RTT due to use of dual-stack links following a very similar path, > >and no "errant" tunnels) > > IIJ would like to peer with Abilene or any other ASes, of course, > if they participate to any of the exchanges we are present. we are > present at: > PAIX palo alto > 6TAP palo alto (L3 IX so there should be no config needed) > NYIIX > 6IIX-NY > and in japan: > NSPIXP6 > NSPIXP2 > JPNAP6 Something for the Abilene folks to comment on... I'm sure Abilene is present natively at one or more of these - the 6TAP especially :) Thus the tunnel point may be moot (although it doesn't help during the IETF as such). Tim From itojun@iijlab.net Sun Nov 17 21:46:36 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Mon, 18 Nov 2002 06:46:36 +0900 Subject: [6bone] IETF IPv6 connectivity In-Reply-To: tjc's message of Sun, 17 Nov 2002 21:25:25 GMT. <20021117212525.GH20267@login.ecs.soton.ac.uk> Message-ID: <20021117214637.EC0DA4B24@coconut.itojun.org> >> if they participate to any of the exchanges we are present. we are >> present at: >> PAIX palo alto >> 6TAP palo alto (L3 IX so there should be no config needed) >> NYIIX >> 6IIX-NY >> and in japan: >> NSPIXP6 >> NSPIXP2 >> JPNAP6 >Something for the Abilene folks to comment on... I'm sure Abilene is present >natively at one or more of these - the 6TAP especially :) Thus the tunnel >point may be moot (although it doesn't help during the IETF as such). i don't get any Abilene route from 6TAP palo alto. and the issue w/ delay to european ASes can only be solved only if Abilene provides us transit... itojun From kato@wide.ad.jp Sun Nov 17 22:03:36 2002 From: kato@wide.ad.jp (Akira Kato) Date: Mon, 18 Nov 2002 07:03:36 +0900 (JST) Subject: [6bone] 6bone-mess-01.txt In-Reply-To: <20021117211003.AB9924B25@coconut.itojun.org> References: <20021117204447.GA20267@login.ecs.soton.ac.uk> <20021117211003.AB9924B25@coconut.itojun.org> Message-ID: <20021118.070336.64774644.kato@wide.ad.jp> > part of the reason is because we IIJ (providing IPv6 connectivity > this time) have policy not to peer over tunnels, to keep quality of > our IPv6 routes/paths. so we have no direct reachability to Europe. > the cause of issue is a bit different from 6bone-mess document. If itojun is able to relax the policy for the tentative connectivities such as IETF venue, by putting two (or more) tunnels to major IPv6 ISPs in U.S. and in Europe repectively, people in Europe will be much happier because their packets don't have to be transmitted across the ponds 6 times in a round-trip in the worst case. -- Akira Kato From nicolas.deffayet@ndsoftware.net Sun Nov 17 23:02:56 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 18 Nov 2002 00:02:56 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C52E@nlcbbms03> References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C52E@nlcbbms03> Message-ID: <1037574175.633.6993.camel@wks1.fr.corp.ndsoftware.com> On Sun, 2002-11-17 at 21:51, Jorgensen, Roger wrote: > You have shown MANY times that you do not have any clue about > how REAL network work, REAL as in real routing hardware and real > links, NOT tunnels and a few BSD/linux boxes with zebra or whatever > you use. Very funny from you: "real links, NOT tunnels". >From your looking-glass (http://www.ipv6.aorta.net/cgi-bin/v6glass.cgi): NL-AMS06D-RE1> show ipv6 tunnel Tun Route LastInp Packets Description 0 - 00:00:03 19002640 AS8733 CHELLO.BE be-bru-ri-01 2 - 00:00:04 1180607 AS8209 CHELLO.NL IPV6 sicks.chello.nl 3 - 00:00:07 231320930 AS65470 AORTA-NO IPV6 4 - 00:00:20 14903986 AS65430 AORTA-AT IPV6 9 - 00:00:43 20176084 AS65530 AORTA-US us-nyc02a-re1 22 - 00:00:07 149907180 AS65460 AORTA-SE IPV6 28 - 00:00:00 160352479 AS6830 CHELLO.DE IPV6 de-fra-ri-01 Very nice, your network have only tunnels ? You don't have REAL links beetween your routers ? Why you don't go to AMS-IX ? NL-AMS06D-RE1 is not on a AMS-IX POP ? If you go to AMS-IX, you can peer natively (without tunnels) with this ISP: 11 - 00:00:17 134364 AS3265 xs4all 14 - 00:00:35 1510577 AS8954 IPng 15 - 00:00:02 57960912 AS25336 XS26 16 - 00:00:56 794761 AS1890 UU.NET NL/EU 30 - 00:00:14 152919 AS1200 AMSIX AIAD 48 - 00:00:08 132504 AS1103 SURFnet It's easy to criticize tunneling and don't try to have a maximum of native peers. > a few BSD/linux boxes with zebra or whatever you use I'm sorry but a lot of ISP use PC box with Zebra in production. There is not differences when you peer with a Zebra, a Cisco, or a Juniper. Go to http://www.wide.ad.jp/nspixp6/peering-status.html, you will see that a lot of ISP use PC box with Zebra. IIJ (sTLA/pTLA): NetBSD 1.5.1 w/ zebra WIDE (sTLA): NetBSD-1.5.1 w/ zebra / GR2000 STCN (sTLA): FreeBSD4.5/zebra0.92a FBDC (sTLA/pTLA): FreeBSD 4.3-STABLE / zebra-0.91a Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From pekkas@netcore.fi Sun Nov 17 23:16:22 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 18 Nov 2002 01:16:22 +0200 (EET) Subject: [6bone] IETF IPv6 connectivity In-Reply-To: <20021117214637.EC0DA4B24@coconut.itojun.org> Message-ID: On Mon, 18 Nov 2002 itojun@iijlab.net wrote: > i don't get any Abilene route from 6TAP palo alto. and the issue w/ > delay to european ASes can only be solved only if Abilene provides us > transit... Easier fix would be to add a few non-transit tunnels and appropriate filters to some prominent operators at rtr1.ietf55.ops.ietf.org or the second hop router. Tunneling over v4 is better because then we'd be able to use our v6 infrastructure at least, even if IIJ has no proper v6 interconnections in place (btw, IMO good interconnections between bigger transits is one of the most important things to get done ASAP). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas@netcore.fi Sun Nov 17 23:30:02 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 18 Nov 2002 01:30:02 +0200 (EET) Subject: [6bone] (no subject) In-Reply-To: Message-ID: On Wed, 13 Nov 2002, Robert J. Rockell wrote: > New 2772 draft. Take a look. Look for "WOOP" in the body for notes. > Largely, only the pTLA requirements are re-written. Send to me with > comments, or the list. We beyond the dealine for submission, but mayve > this can serve as good discussion points for Tuesday lunch meeting at IETF. I'll only comment on the old parts which haven't really changed, for now. 1) Scope of the document should state (this is mentioned later in the doc, last sentece of section 4) that the rules could also be usable to RIR space users, not just 6bone but. 2) subsections under section 3 could be compressed -- just lists of things not to allow or what to allow. There's a lot of replicated text that doesn't really add much. 3) 3.4, change FF08::/16 and FF18::/16 to FFx8::/16 (prefix based mcast addresses etc have since been specified) 4) 3.10 on 6to4 is a bit out-of-date 5) section 4 might be a bit compressable also 6) I'm not sure whether registering all the leaf sites etc. in the registry is all that useful. It just adds clutter there. I'd be more interest in a registry which only has important links there. (Compare a huge list of leaf sites, pTLA's, pNLA's etc. mingled in one big mess in the "tunnels" section). Editorial, ==> s/aggreement/agreement/g ==> s/as describe in/as described in/ ==> s/informatino/information/ ==> s/mimimum/minimum/ ==> s/acess/access/ ==> s/guildelines/guidelines/g ==> s/unduely/unduly/ ==> s/repremand/reprimant/ Eventually, the Internet registries will assign prefixes under other than the 6Bone TLA (3FFE::/16). Registry assigned prefixes (currently ==> s/Eventually, the//, s/will assign/are assigning/ 5. The pTLA Applicant MUST have a valid Public Autonomous System Number. Request for pTLA under private Autonomous System (ASN 64512 thru 65535) numbers will not be entertained. ==> or reserved.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas@netcore.fi Mon Nov 18 00:08:37 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 18 Nov 2002 02:08:37 +0200 (EET) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: Message-ID: On 16 Nov 2002, Robert Kiessling wrote: > Here is a rather radical proposal: > > Peerings between 6bone sites MUST NOT carry any other routes apart > from 3FFE and a summary route for 2001/3. Indeed, this is a rather radical -- and interesting -- proposal. My worry is whether this would work as we expect. More often than not, RIR space owners' routing is equally messy than anyone else's, possibly because it has been seen as a way to survive. The above proposal would be good in the "last dying throes" of 6bone -- when there actually _is_ native (or otherwise good) and organized connectivity between 2001::/16 sites. Currently there definitely is *NOT*. In summary, I believe it may be too early for this. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From itojun@iijlab.net Mon Nov 18 00:12:58 2002 From: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Mon, 18 Nov 2002 09:12:58 +0900 Subject: [6bone] IETF IPv6 connectivity In-Reply-To: pekkas's message of Mon, 18 Nov 2002 01:16:22 +0200. Message-ID: <20021118001258.1FC167AF@starfruit.itojun.org> to non-IETF participants: sorry for the noise. >> i don't get any Abilene route from 6TAP palo alto. and the issue w/ >> delay to european ASes can only be solved only if Abilene provides us >> transit... >Easier fix would be to add a few non-transit tunnels and appropriate >filters to some prominent operators at rtr1.ietf55.ops.ietf.org or the >second hop router. note: the venue is leaf /48 site and does not run BGP. if you *really* need a special tunnel from the venue to your AS, tell me: - tunnel endpoint - your address space (e.g. 2001:xxxx::/32) then i'll try to put tunnel as well as static route to you. you will need to statically route 2001:240:5ff::/48 to the venue. itojun From paul@clubi.ie Mon Nov 18 00:44:30 2002 From: paul@clubi.ie (Paul Jakma) Date: Mon, 18 Nov 2002 00:44:30 +0000 (GMT) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037545057.611.5797.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On 17 Nov 2002, Nicolas DEFFAYET wrote: > A lot of sTLA don't have a good routing (they don't use filtering, > MED,...) MED attribute is non-transitive. it doesnt get passed along - doesnt do much except for peers with whom you have multiple links. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: FORTUNE'S FUN FACTS TO KNOW AND TELL: #44 Zebras are colored with dark stripes on a light background. From yjchui@cht.com.tw Mon Nov 18 00:59:49 2002 From: yjchui@cht.com.tw (yjchui) Date: Mon, 18 Nov 2002 08:59:49 +0800 Subject: [6bone] ipv6 on c827 References: <20021114193128.C9841@ns1.arch.bellsouth.net> <20021115062126.GP13765@oleane.net> Message-ID: <00dc01c28e9d$ccb1a8c0$27a9900a@twinkletaipei> Hi: Does c827 mean Cisco 827? If does, it supports IPv6. I have tested the IPv6 ADSL function with the equipment. Regards Yann-Ju Chu ChungHwa Telecom. Co. E-mail: yjchui@cht.com.tw ----- Original Message ----- From: "Jean-Claude Christophe" To: "Christian Kuhtz" Cc: <6bone@ISI.EDU> Sent: Friday, November 15, 2002 2:21 PM Subject: Re: [6bone] ipv6 on c827 > hey Christian, > > There are no IPv6 support for the 820 series yet. > > Regards, > > According to Christian Kuhtz : > > hey gang, > > > > if there's anybody else 6bone'ing with a c827, please get in touch > > with me ;).. > > > > thanks, > > christian > > > > _______________________________________________ > > 6bone mailing list > > 6bone@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/6bone > > -- > Jean-Claude Christophe / jch@oleane.net > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From alex@bit.nl Mon Nov 18 06:53:45 2002 From: alex@bit.nl (Alex Bik) Date: Mon, 18 Nov 2002 07:53:45 +0100 (MET) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037574175.633.6993.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On 18 Nov 2002, Nicolas DEFFAYET wrote: > Very nice, your network have only tunnels ? You don't have REAL links > beetween your routers ? I think the guys at chello/upc have more real links than you can ever dream of. > 11 - 00:00:17 134364 AS3265 xs4all > 14 - 00:00:35 1510577 AS8954 IPng > 15 - 00:00:02 57960912 AS25336 XS26 > 16 - 00:00:56 794761 AS1890 UU.NET NL/EU > 30 - 00:00:14 152919 AS1200 AMSIX AIAD > 48 - 00:00:08 132504 AS1103 SURFnet Maybe you should get your fact straight first. There are a more ASes you can peer IPv6 with at the AMS-IX. Besides, Chello *IS* at AMS-IX. > It's easy to criticize tunneling and don't try to have a maximum of > native peers. It's easy to criticize indeed. Especially if you don't know what you are talking about. > I'm sorry but a lot of ISP use PC box with Zebra in production. > There is not differences when you peer with a Zebra, a Cisco, or a > Juniper. Sure kiddo, you're right. Maybe we shouldn't blame you for not knowing better. You've probably never *seen* an IXP (I mean a *real* one, with connected members 'n stuff). Maybe you should read a little about the difference between ASIC and CPU based routing. Even (some) Cisco's don't need their CPU to forward every bit in a packet. -- __________________ Met vriendelijke groet, /\ ___/ Alex Bik /- \ _/ Business Internet Trends BV AB2298-RIPE /--- \/ __________________ From bjorn@mork.no Mon Nov 18 10:08:52 2002 From: bjorn@mork.no (=?iso-8859-1?q?Bj=F8rn?= Mork) Date: Mon, 18 Nov 2002 11:08:52 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037560118.635.6461.camel@wks1.fr.corp.ndsoftware.com> (Nicolas DEFFAYET's message of "17 Nov 2002 20:08:39 +0100") References: <002a01c28e52$1953f3f0$210d640a@unfix.org> <1037560118.635.6461.camel@wks1.fr.corp.ndsoftware.com> Message-ID: Nicolas DEFFAYET writes: > BGP choose the route(s) with shorter ASpath and lower MED. MED won't matter unless you have multiple links to the _same_ AS. See e.g. http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a0080094431.shtml Bjørn From nicolas.deffayet@ndsoftware.net Mon Nov 18 10:49:29 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 18 Nov 2002 11:49:29 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: References: Message-ID: <1037616569.642.8498.camel@wks1.fr.corp.ndsoftware.com> On Mon, 2002-11-18 at 07:53, Alex Bik wrote: > > Very nice, your network have only tunnels ? You don't have REAL links > > beetween your routers ? > > I think the guys at chello/upc have more real links than you can ever > dream of. I mean IPv6 links of course... > > 11 - 00:00:17 134364 AS3265 xs4all > > 14 - 00:00:35 1510577 AS8954 IPng > > 15 - 00:00:02 57960912 AS25336 XS26 > > 16 - 00:00:56 794761 AS1890 UU.NET NL/EU > > 30 - 00:00:14 152919 AS1200 AMSIX AIAD > > 48 - 00:00:08 132504 AS1103 SURFnet > > Maybe you should get your fact straight first. There are a more ASes you > can peer IPv6 with at the AMS-IX. Besides, Chello *IS* at AMS-IX. I know who is at AMS-IX, thanks. I talked about _current_ peer of Chello/UPC/AORTA (AS6830). > > I'm sorry but a lot of ISP use PC box with Zebra in production. > > There is not differences when you peer with a Zebra, a Cisco, or a > > Juniper. > > Maybe you should read a little about the difference between ASIC and CPU > based routing. Even (some) Cisco's don't need their CPU to forward every > bit in a packet. Roger wrote "You have shown MANY times that you do not have any clue about how REAL network work, REAL as in real routing hardware and real links, NOT tunnels and a few BSD/linux boxes with zebra or whatever you use.", he don't talk about routing performance.... REAL network (like Roger said) can use Zebra for routing (see my previous email..). Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From alex@bit.nl Mon Nov 18 11:26:23 2002 From: alex@bit.nl (Alex Bik) Date: Mon, 18 Nov 2002 12:26:23 +0100 (MET) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037616569.642.8498.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On 18 Nov 2002, Nicolas DEFFAYET wrote: > REAL network (like Roger said) can use Zebra for routing (see my > previous email..). Sure thing. And monkeys may fly out of my butt. -- __________________ Met vriendelijke groet, /\ ___/ Alex Bik /- \ _/ Business Internet Trends BV AB2298-RIPE /--- \/ __________________ From gert@space.net Mon Nov 18 14:13:45 2002 From: gert@space.net (Gert Doering) Date: Mon, 18 Nov 2002 15:13:45 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: ; from pekkas@netcore.fi on Thu, Nov 14, 2002 at 10:03:24PM +0200 References: Message-ID: <20021118151345.Q94537@Space.Net> Hi, On Thu, Nov 14, 2002 at 10:03:24PM +0200, Pekka Savola wrote: > The next question would be whether we want to keep 6bone de-facto free and > open, and a "big mess", or try to do something about it. Views differ on > this one; the options are basically (I hope I didn't miss any): > 1) keep 6bone routing as it is, build totally separate competing v6 > Internet for "production" > 2) try to move 6bone-style routing off to the edges of the network > a) try to clean up the current mess, or > b) prevent any further mess in new-pTLA rules > 3) kill 6bone I like Robert's approach. Keep the 6bone for whatever experiments people want to do, but make sure that no transit of non-6bone-space goes through 6bone sites. 2001::/16 people have their own stability issues, but as those are all commercial entities, I assume more interest in stabilizing IPv6 routing over here (I'm part of the 2001:: mess). The commercial world has their own mechanisms to clean up "bad routing" - like bad RTTs, packet loss, occasional unreachabilites due to routing loops, and so on. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 49875 (48540) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From dr@cluenet.de Mon Nov 18 14:34:04 2002 From: dr@cluenet.de (Daniel Roesen) Date: Mon, 18 Nov 2002 15:34:04 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: ; from bjorn@mork.no on Mon, Nov 18, 2002 at 11:08:52AM +0100 References: <002a01c28e52$1953f3f0$210d640a@unfix.org> <1037560118.635.6461.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021118153404.A32518@homebase.cluenet.de> On Mon, Nov 18, 2002 at 11:08:52AM +0100, Bjørn Mork wrote: > Nicolas DEFFAYET writes: > > BGP choose the route(s) with shorter ASpath and lower MED. > > MED won't matter unless you have multiple links to the _same_ AS. or using "always-compare-med" Regards, Daniel From pekkas@netcore.fi Mon Nov 18 15:04:01 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 18 Nov 2002 17:04:01 +0200 (EET) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: Message-ID: On Mon, 18 Nov 2002, Bjørn Mork wrote: > Nicolas DEFFAYET writes: > > > BGP choose the route(s) with shorter ASpath and lower MED. > > MED won't matter unless you have multiple links to the _same_ AS. unstated background is that Mr Deffayet is using "always-compare-med". -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From bjorn@mork.no Mon Nov 18 16:45:43 2002 From: bjorn@mork.no (=?iso-8859-1?q?Bj=F8rn?= Mork) Date: Mon, 18 Nov 2002 17:45:43 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: (Pekka Savola's message of "Mon, 18 Nov 2002 17:04:01 +0200 (EET)") References: Message-ID: Pekka Savola writes: > On Mon, 18 Nov 2002, Bjørn Mork wrote: >> Nicolas DEFFAYET writes: >> >> > BGP choose the route(s) with shorter ASpath and lower MED. >> >> MED won't matter unless you have multiple links to the _same_ AS. > > unstated background is that Mr Deffayet is using "always-compare-med". With 90+ uncoordinated peers? Doesn't that result in more or less random routing? Bjørn From nicolas.deffayet@ndsoftware.net Mon Nov 18 18:45:25 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 18 Nov 2002 19:45:25 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: References: Message-ID: <1037645124.628.9721.camel@wks1.fr.corp.ndsoftware.com> On Mon, 2002-11-18 at 17:45, Bjørn Mork wrote: > Pekka Savola writes: > > On Mon, 18 Nov 2002, Bjørn Mork wrote: > >> Nicolas DEFFAYET writes: > >> > >> > BGP choose the route(s) with shorter ASpath and lower MED. > >> > >> MED won't matter unless you have multiple links to the _same_ AS. > > > > unstated background is that Mr Deffayet is using "always-compare-med". > > With 90+ uncoordinated peers? Doesn't that result in more or less > random routing? http://noc.ndsoftwarenet.com/stats/aspath-tree/bgp-page-complete.php Our routing is very clean and not random. BGP peers who receive full transit from us, can choose to get only native routes by using BGP communities. -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From Aphollis@aol.com Mon Nov 18 21:37:50 2002 From: Aphollis@aol.com (Aphollis@aol.com) Date: Mon, 18 Nov 2002 16:37:50 -0500 Subject: [6bone] finding a contact Message-ID: <05ED4CF9.0A84E5EF.006E76AC@aol.com> Hi, My name is Adam Hollis and I am conducting a project at Chico State where I am setting up an IPv6 host (Windows XP) to a 3640 Cisco router. Then I want to be able to tunnel through an IPv4 network and so forth. I was hoping that you could help me find a contact so I can get an IPv6 address for this project. Any help would be great. Thank you, Adam Hollis From paul@clubi.ie Mon Nov 18 22:48:54 2002 From: paul@clubi.ie (Paul Jakma) Date: Mon, 18 Nov 2002 22:48:54 +0000 (GMT) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: Message-ID: On Mon, 18 Nov 2002, Alex Bik wrote: > On 18 Nov 2002, Nicolas DEFFAYET wrote: > > > REAL network (like Roger said) can use Zebra for routing (see my > > previous email..). > > Sure thing. And monkeys may fly out of my butt. ah come on now... that's not fair. zebra /is/ used in real networks, and more specifically has a niche in IPv6 routing due to it being one of the more accessible IPv6 routing platforms. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam@dishone.st Fortune: Our informal mission is to improve the love life of operators worldwide. -- Peter Behrendt, president of Exabyte From rrockell@sprint.net Mon Nov 18 23:34:39 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Mon, 18 Nov 2002 18:34:39 -0500 (EST) Subject: [6bone] Meeting tomorrow about 6bone routing goop. Message-ID: So I am still trying to find a room. I will mail the list as soon as we are able to settle on one, as well as post on the message board right near the registration desk. If all else fails, meet by the escalators and we'll go somewhere where we can all chat. Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- From rrockell@sprint.net Mon Nov 18 23:35:03 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Mon, 18 Nov 2002 18:35:03 -0500 (EST) Subject: [6bone] Re: Meeting tomorrow about 6bone routing goop. In-Reply-To: Message-ID: Also, if not clear before, meeting is Tuesday, 11:30 AM (at the conclusion of the morning sessions). Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On Mon, 18 Nov 2002, Robert J. Rockell wrote: ->So I am still trying to find a room. I will mail the list as soon as we are ->able to settle on one, as well as post on the message board right near the ->registration desk. If all else fails, meet by the escalators and we'll go ->somewhere where we can all chat. -> -> ->Thanks ->Rob Rockell ->SprintLink ->(+1) 703-689-6322 ->----------------------------------------------------------------------- -> -> From rrockell@sprint.net Mon Nov 18 23:42:38 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Mon, 18 Nov 2002 18:42:38 -0500 (EST) Subject: [6bone] 6Bone backbone meeting; Moved back to noon! Message-ID: Updated: 12:00 (noon) Tuesday. Room is called "State" (Conference level, behind escalators). We'll have 1 hour from 12:00-1:00 Agenda: Pekka's 6bone-mess draft 2772bis (delta's from previous) Michel Py's thoughts on the 6bone. See you there. Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- From nicolas.deffayet@ndsoftware.net Mon Nov 18 23:44:58 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 19 Nov 2002 00:44:58 +0100 Subject: [6bone] finding a contact In-Reply-To: <05ED4CF9.0A84E5EF.006E76AC@aol.com> References: <05ED4CF9.0A84E5EF.006E76AC@aol.com> Message-ID: <1037663098.611.10098.camel@wks1.fr.corp.ndsoftware.com> On Mon, 2002-11-18 at 22:37, Aphollis@aol.com wrote: Hi Adam, > My name is Adam Hollis and I am conducting a project at Chico State where I am setting up an IPv6 host (Windows XP) to a 3640 Cisco router. Then I want to be able to tunnel through an IPv4 network and so forth. I was hoping that you could help me find a contact so I can get an IPv6 address for this project. Any help would be great. In California, you have this pTLA: http://whois.6bone.net/cgi-bin/whois?esnet http://whois.6bone.net/cgi-bin/whois?isi-lap http://whois.6bone.net/cgi-bin/whois?cisco http://whois.6bone.net/cgi-bin/whois?digital-ca Try to contact them. Best regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From bjorn@mork.no Tue Nov 19 11:39:10 2002 From: bjorn@mork.no (=?iso-8859-1?q?Bj=F8rn?= Mork) Date: Tue, 19 Nov 2002 12:39:10 +0100 Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: <1037645124.628.9721.camel@wks1.fr.corp.ndsoftware.com> (Nicolas DEFFAYET's message of "18 Nov 2002 19:45:25 +0100") References: <1037645124.628.9721.camel@wks1.fr.corp.ndsoftware.com> Message-ID: Nicolas DEFFAYET writes: > On Mon, 2002-11-18 at 17:45, Bjørn Mork wrote: >> Pekka Savola writes: >> > On Mon, 18 Nov 2002, Bjørn Mork wrote: >> >> Nicolas DEFFAYET writes: >> >> >> >> > BGP choose the route(s) with shorter ASpath and lower MED. >> >> >> >> MED won't matter unless you have multiple links to the _same_ AS. >> > >> > unstated background is that Mr Deffayet is using "always-compare-med". >> >> With 90+ uncoordinated peers? Doesn't that result in more or less >> random routing? > > http://noc.ndsoftwarenet.com/stats/aspath-tree/bgp-page-complete.php > > Our routing is very clean and not random. Sorry, the word I was looking for wasn't really "random" but "arbitrary". You prefer routes with MED to routes without MED (or vice versa if you are using Cisco defaults). I don't think most of your peers would expect them to suddenly become the preferred path just because they set a default MED. What advantages do route selection based on MED give you? Bjørn From itojun@iijlab.net Tue Nov 19 13:06:12 2002 From: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Tue, 19 Nov 2002 22:06:12 +0900 Subject: [6bone] 2001:240::/35 ghost route Message-ID: <20021119130612.B7E027B1@starfruit.itojun.org> we (IIJ, AS2497) have migrated from 2001:240::/35 to 2001:240::/32. we stopped announcement of 2001:240::/35 on oct 16. however, junk routes are still floating around (via AS6175 and/or AS145). also i got a report that AS1103 is sourcing 2001:240::/32. so (1) if you see 2001:240::/35, filter them out. (2) if you see 2001:240::/32 from someone other than AS2497, please report. (3) if you are AS contact for the above ASes (6175, 145, 1103) check if your router is behaving correctly. it is known that some of the publically-available BGP code misbehaves on withdraw. thanks. itojun --- topmost line and bottom line are TOTALLY WRONG * 2001:240::/35 2001:948:0:F000::1 0 2603 11537 145 6175 2497 i *>i 2001:708:0:F000::A:1 100 0 3274 5539 4589 2497 i *> 2001:240::/32 2001:948:0:F000::1 200 0 2603 6680 1103 i From bmanning@ISI.EDU Tue Nov 19 14:24:47 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 19 Nov 2002 06:24:47 -0800 (PST) Subject: [6bone] 3ffe/2001:0 et.al. In-Reply-To: from Paul Jakma at "Nov 18, 2 10:48:54 pm" Message-ID: <200211191424.gAJEOlZ10952@boreas.isi.edu> Ok, so here is an alternate view presume AS 4554 has the following delegations: 3ffe:08::/24 2001:0478::/32 and there is a mix of hosts, routers, and links (local/wide) local links all run native IPv6 and there is a mix of native and tunneled IPv6 over the wan links. Due to acidents of history, 3ffe and 2001 addresses are used on both lan and wan links. Perhaps it would be worthwhile to ask folks to consider doing the following: for native IPv6 connections, use 2001 space. for tunnels between IPv6 islands over IPv4 only space, use 3ffe space. this will ensure that, at least for AS 4554, any exposure of 3ffe space will reflect the "knitting" of native IPv6 networks together over tunneled environments. e.g. the 6bone. then comes the fun part... :) AS 4554 would be injecting a single 3ffe prefix into the routing system, 3ffe:08::/24. Thats a whole bunch of p2p tunnels. There are only ~30 tunnels for this AS. One could renumber all the tunnels into one end of the address range, making the effective used space something like: 3ffe:8::/120 AS 4554 would like to remove the 3ffe:08::/24 in the routing system and replace it in the routing system with 3ffe:08::/120 As AS 4554 removes/replaces tunnels with native connectivity, the routing announcement will shrink, from a /120, to a /122, to a /126 and then zero, which indicates that AS 4554 is no longer using tunnels to link v6 islands (e.g. no 6bone!) --bill From itojun@iijlab.net Tue Nov 19 14:58:09 2002 From: itojun@iijlab.net (Jun-ichiro itojun Hagino) Date: Tue, 19 Nov 2002 23:58:09 +0900 Subject: [6bone] 2001:240::/35 ghost route In-Reply-To: itojun's message of Tue, 19 Nov 2002 22:06:12 +0900. <20021119130612.B7E027B1@starfruit.itojun.org> Message-ID: <20021119145809.0D7397B2@starfruit.itojun.org> > we (IIJ, AS2497) have migrated from 2001:240::/35 to 2001:240::/32. > we stopped announcement of 2001:240::/35 on oct 16. however, > junk routes are still floating around (via AS6175 and/or AS145). > also i got a report that AS1103 is sourcing 2001:240::/32. correction - we (AS2497) still are advertising 2001:240::/35, to defend against ghost routes. sorry for the confusion. so, (1) if you see 2001:240::/35 or 2001:240::/32 source by other parties, let us know. itojun From pekkas@netcore.fi Tue Nov 19 16:17:19 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Tue, 19 Nov 2002 18:17:19 +0200 (EET) Subject: [6bone] RFC2772 rewrite -- bigger scope goals In-Reply-To: Message-ID: On Tue, 19 Nov 2002, Bjørn Mork wrote: > What advantages do route selection based on MED give you? MED is only considered on equally long paths, contrary to local-preference. (There are some caveats to using MED like this, like the origin of the route being IGP vs unknown.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From dragon@tdoi.org Tue Nov 19 17:15:51 2002 From: dragon@tdoi.org (Christian Nickel) Date: Tue, 19 Nov 2002 18:15:51 +0100 Subject: [6bone] Fw: Filtering Message-ID: <001601c28fef$501081d0$fd04a80a@alpha> hi 6bone folks, i got a nice mail from Deffayet greets Christian ----- Original Message ----- From: "Nicolas DEFFAYET" To: Cc: ; ; ; Sent: Tuesday, November 19, 2002 12:36 AM Subject: Filtering > Hi kiddie, ah he is talking to himself :) > > I'm glad to announce that NDSoftware (AS25358) has setup filters for > drop any packets from and to 2001:658:217::/48, 2001:618:B::/48, > 2001:768:1800::/40. > > >From your website (http://www.tdoi.org): > "Our Autonomous System does not accept prefix 3ffe:4013::/32. > Any route via AS25358 will be removed. > You cannot reach any prefix routed via AS25358!" > > It's too funny. yes it is funny :) > > You don't have an Autonomous System, you have a private ASN with 2 /48 > and 1 /40 for play. and my prefixes are not for playing like your privateTLA it is production space > You are an inmensly irritating clueless kiddie who want to impress other > 6bone / ipv6 users. > > Your filtering is not a problem because you are the only user of your > network. > > Our filtering will be a problem for you because we provide transit to > many AS. People who transit via our network can't will reach you. transit to many AS? wow ;) > > > Have a nice day with your broken IPv6 network. oh yes it is now really broken > > Best Regards, > > -- > Nicolas DEFFAYET, NDSoftware > NOC Website: http://noc.ndsoftwarenet.com/ > FNIX6: http://www.fnix6.net/ > > From Sascha Bielski Tue Nov 19 17:28:51 2002 From: Sascha Bielski (Sascha Bielski) Date: Tue, 19 Nov 2002 18:28:51 +0100 Subject: [6bone] Fw: Filtering In-Reply-To: <001601c28fef$501081d0$fd04a80a@alpha> References: <001601c28fef$501081d0$fd04a80a@alpha> Message-ID: <128767705312.20021119182851@rdns.de> Dear Christian Nickel, > hi 6bone folks, > i got a nice mail from Deffayet >> >> I'm glad to announce that NDSoftware (AS25358) has setup filters for >> drop any packets from and to 2001:658:217::/48, 2001:618:B::/48, >> 2001:768:1800::/40. >> >> >From your website (http://www.tdoi.org): >> "Our Autonomous System does not accept prefix 3ffe:4013::/32. >> Any route via AS25358 will be removed. >> You cannot reach any prefix routed via AS25358!" >> >> It's too funny. blah blah blah, can't you just stop fighting? christian, the filtering is just a provocation, so now Nicolas filters back. senseless. >> Have a nice day with your broken IPv6 network. have a nice day with your f*cking fights. and PLEASE don't blame the 6bone mailing list with that crap, we want to to serious talk about serious problems, not about kiddish problems, cheers -- best regards, Sascha Bielski mailto:sb@rdns.de xs26.net German Coordination phone: +49 (0) 174 / 432 93 76 email: sb@rdns.de From Willem@Grooters.100.nl Tue Nov 19 19:34:57 2002 From: Willem@Grooters.100.nl (Willem Grooters) Date: Tue, 19 Nov 2002 20:34:57 +0100 Subject: [6bone] Information request Message-ID: <000201c29004$41ceb550$0100a8c0@home.grooters.100.nl> Hello on the 6bone I'm not new to IPV4 - though more a programmer for over e decade than network specialist - and I'd like to know more on IPV6 - and use it. I've read some literature on the subject, most RFC's concerning IPV6 but given the discussions on this forum during the last month I hardly thinkthis forum can be of any help, since the discussions seem to be more about political issues (the whole rubbish on NDSOFTWARE.NET) than helping anyone to get some idea on how to get on with IPV6.... Still, I'll give it a try. I have: 1 Alpha running OpenVMS 7.3-1 (which is said to be IPV6 ready) 2 Intel W2K machines, I downloaded the IPV6-perview for this 1 WindowsME, I downloaded Trumpet IPV6 stack already. I _will_ have an ADSL connection within a few weeks, but I don't thinmk the router I'll have to use is IPV6 ready (still have to ask). i _could_ use an old PC running Linux, but it will be an older RedHat implementation (newest do not install....) For the Windows machines, I'm NOT upgrading to XP (which seems to have an IPV6 stack somehow) All connected using FastEthernet. What I did understand from the site is that Windows might have a problem. How to get over it? I don't think the local network would be a problem. But what about connecting to the Internet? My ISP doesn't connect over IPV6 yet, so I'll have to use 6to4, probably. Where: On the VMS-box? On a router (be it Linux, FreeBSD or whatever). Can I use a modem in stead of a 'fixed'connection (I would think yes, but like to have confirmation). In that case, I'll need 6to4 on a PC.... Any good books to read? I intend to stay an end-node, for now. Willem Grooters e-mail: Willem.Grooters.100.nl From jeroen@unfix.org Tue Nov 19 21:08:23 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Tue, 19 Nov 2002 22:08:23 +0100 Subject: [6bone] Information request In-Reply-To: <000201c29004$41ceb550$0100a8c0@home.grooters.100.nl> Message-ID: <003401c2900f$cc1b8520$210d640a@unfix.org> Willem Grooters wrote: > Hello on the 6bone > > I'm not new to IPV4 - though more a programmer for over e decade than > network specialist - and I'd like to know more on IPV6 - and use it. > I've read some literature on the subject, most RFC's > concerning IPV6 but > given the discussions on this forum during the last month I > hardly thinkthis > forum can be of any help, since the discussions seem to be more about > political issues (the whole rubbish on NDSOFTWARE.NET) than > helping anyone > to get some idea on how to get on with IPV6.... > Still, I'll give it a try. Quite unfortunate that you read it like that, but it was like that. Politics are required to keep things moving around otherwise it will all turn into a big mess (See Pekka's draft about that :). Though there is much help to be found here ofcourse. Biggest help to most people will be http://hs247.com containing many links to documentation (RFC's etc), resources and tunnelbrokers. It also serves as the main "IPv6 News" site. > I have: > > 1 Alpha running OpenVMS 7.3-1 (which is said to be IPV6 ready) These will work I heared from a certain person called snore. If you need more info I can ping him around to you. > 2 Intel W2K machines, I downloaded the IPV6-perview for this Works perfectly. > 1 WindowsME, I downloaded Trumpet IPV6 stack already. Unknown to me, I refuse to use 9x due to many reasons ;) > I _will_ have an ADSL connection within a few weeks, but I > don't thinmk the router I'll have to use is IPV6 ready (still have to ask). XS4all (www.xs4all.nl) PowerDSL does native IPv6. As for most others most other dutch ADSL you will need to setup a tunnel to a tunnelbroker (see below). XS4all have their own btw (http://service.xs4all.nl/ipv6/) Concepts (www.supersneladsl.nl :) uses a SixXS POP (see below) > i _could_ use an old PC running Linux, but it will be an older RedHat > implementation (newest do not install....) > For the Windows machines, I'm NOT upgrading to XP (which > seems to have an IPV6 stack somehow) The IPv6 Previews work just fine. > All connected using FastEthernet. > > What I did understand from the site is that Windows might > have a problem. Windows NT based products work fine, I personally don't have experience with 9x and IPv6. > How to get over it? > I don't think the local network would be a problem. But what about > connecting to the Internet? My ISP doesn't connect over IPV6 > yet, so I'll have to use 6to4, probably. Where: On the VMS-box? On a > router (be it Linux, FreeBSD or whatever). > Can I use a modem in stead of a 'fixed'connection (I would > think yes, but like to have confirmation). In that case, I'll need 6to4 on a PC.... IMHO 6to4 is not so good especially as there are at least 2 "big" tunnelbrokers in holland: http://www.xs26.net http://www.sixxs.net (IPng.nl is provisioned by them now also) They both can provide you with a tunnel and a subnet. Note that xs26 has multiple POPs and you can connect to all of them routing the same prefix over those tunnels, while sixxs has multiple POPs but to completely distinct networks. Thus your milage may vary. Read the websites, snoop around and find out. 6to4 usually goes over cselt (tilab) which is not really 'local' :) > Any good books to read? Christian Huitema's book available at most Donner's (the bookchain with the ";)"). %T IPv6: The New Internet Protocol %A Huitema, Christian %I Prentice Hall %C Englewood Cliffs, New Jersey %D 1996 %O paperback, index %G ISBN 0-13-241936-X %P vii,188pp Or check http://dannyreviews.com/h/IPv6.html and ofcoure "Christian Huitema IPv6" in google. Greets, Jeroen From Arnaud Willem Tue Nov 19 21:34:11 2002 From: Arnaud Willem (Arnaud Willem) Date: Tue, 19 Nov 2002 22:34:11 +0100 Subject: [6bone] Fw: Filtering In-Reply-To: <001601c28fef$501081d0$fd04a80a@alpha> References: <001601c28fef$501081d0$fd04a80a@alpha> Message-ID: <20021119213411.GA12480@in.woof.lu> --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I've been following this from far away since some time now, but I think that this is going a bit too far, don't you think? On Tue, Nov 19, 2002 at 06:15:51PM +0100, Christian Nickel wrote: [...]=20 >=20 > > Hi kiddie, >=20 > ah he is talking to himself :) >=20 Well, if you start your e-mails this way, I understand why you are not getting much sympathy from him.. > >=20 > > I'm glad to announce that NDSoftware (AS25358) has setup filters for > > drop any packets from and to 2001:658:217::/48, 2001:618:B::/48, > > 2001:768:1800::/40. > >=20 > > >From your website (http://www.tdoi.org): > > "Our Autonomous System does not accept prefix 3ffe:4013::/32. > > Any route via AS25358 will be removed. > > You cannot reach any prefix routed via AS25358!" > >=20 > > It's too funny. >=20 > yes it is funny :) >=20 Woooohoooo! Filtering routes! What a great idea! You claim that you are using your IP subnets for "production space", but, I must say I'm a bit lost on this one: why do you announce that you are going to filter A WHOLE /32 OUT? And even more, a whole AS! =46rom what I can see in your looking glass, the pTLA is not appearing in it. =46rom what I can see in NDSOFTWARE's looking glass, your network, at least, the aggregated /32 of it is still routed there! > >=20 > > You don't have an Autonomous System, you have a private ASN with 2 /48 > > and 1 /40 for play. >=20 > and my prefixes are not for playing like your privateTLA=20 > it is production space >=20 > > You are an inmensly irritating clueless kiddie who want to impress other > > 6bone / ipv6 users. > >=20 > > Your filtering is not a problem because you are the only user of your > > network. > >=20 > > Our filtering will be a problem for you because we provide transit to > > many AS. People who transit via our network can't will reach you. >=20 > transit to many AS? wow ;) >=20 I will not comment on this, as you are both, in this case being childish, IMHO. ("I've got the biggest one!") > >=20 > >=20 > > Have a nice day with your broken IPv6 network. >=20 > oh yes it is now really broken=20 >=20 > >=20 > > Best Regards, > > I think that a nice quote would fit in perfectly in this case: "Der kluegere gibt nach." I don't know which one of you it is, but I hope that you'll stop fighting around this way. Yours truly, Arnaud Willem PS: I haven't got any AS number, I might only be a newbie, but this is complete NONSENSE! --=20 Arnaud Willem woof (at) woof.lu Tue 23:56:20 < don-o> the problem is that emacs is as intuitive as a=20 particle collider --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE92q5Tgv7AoyDfeSoRAtbuAKDd7UaMKdjW/Djvnnm2RNNy9ueh3wCeN/3a cyjLE2sqDTGkMJGjMeGLN3E= =KR7c -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From laurent@forum-auto.com Tue Nov 19 21:36:39 2002 From: laurent@forum-auto.com (Laurent - Forum-auto.com) Date: Tue, 19 Nov 2002 22:36:39 +0100 Subject: [6bone] Re : Filtering Message-ID: <000d01c29013$bec19050$0100a8c0@kally.net> Christian, As I was saying to you by private mail, I'm very surprised that a "professionnal" like you is playing to stupid things like filtering traffic. > and my prefixes are not for playing like your privateTLA > it is production space I would be very happy to know what kind of "production space" apply stupids filters ??? I've found that you have removed it, good idea, it was ridiculous ! (it seems you added it in static) >> transit to many AS? wow ;) If I were you I would not laught about that... You should be very happy that Ndsoftware seems not to have apply such a filter... Moreover, the Ipv6-FR project is not a hoax ;) Ndsoftware help ipv6 to be developped in France, as you can see it in this news from an important Data Center in France (Paris) http://www.telecity.fr/news_and_events.html (In french) http://www.telecity.com/mailer1.html (in english) Unfortunaly, it's not with www.tdoi.org (that seems to be plugged by ISDN !) we'll be able to view what kind of "professional activity" you do Christian ? Christian Nickel, what is your problem ? It would be great to explain this to this community... Laurent HOFMANN From berni@birkenwald.de Tue Nov 19 23:54:31 2002 From: berni@birkenwald.de (Bernhard Schmidt) Date: Wed, 20 Nov 2002 00:54:31 +0100 Subject: [6bone] Re : Filtering In-Reply-To: <000d01c29013$bec19050$0100a8c0@kally.net> References: <000d01c29013$bec19050$0100a8c0@kally.net> Message-ID: <20021119235431.GA99094@thor.birkenwald.de> On Tue, Nov 19, 2002 at 10:36:39PM +0100, Laurent - Forum-auto.com wrote: Hi Laurent, > >> transit to many AS? wow ;) > If I were you I would not laught about that... You should be very happy > that Ndsoftware seems not to have apply such a filter... If I were you I would be happy that NDsoftware has not applied such a filter (or at least removed it), it would probably have been the end of NDs pTLA at all (I believe most people would have filtered him after doing such a crap). You probably do not understand the difference between Christian's way of filtering and Nicolas' way. Christian drops the whole ND pTLA in his BGP, so 3ffe:4013::/32 is just nonexistent to him. Nicolas instead does not filter on BGP level (because we do not announce 2001:768:1800::/40 so he can't filter it, pretty easy heh?) but on Layer3/4 with some packet filtering. The network he wants to blackhole (2001:768:1800::/40) is a subset of our prefix (2001:768::/32), which he accepts and announces to other peers. Now for the difference... viewed only from the local system both ways have the same effect... the filtered prefix is just not available. Christian cannot reach Nicolas because he has no route for this, and Nicolas cannot reach Christian because he filtered it in a packet filter or something like that. But now we assume both have a "multihomed" downstream (multihomed because they have bgp sessions to two or more IPv6 ASes and therefor are computing the used upstream by bgp prefixes... or they provide transit to other providers and so on) Christian does not announce 3ffe:4013::/32 to his downstream. If the downstream has another peer he will probably get the prefix from the other upstream and go this way. So his downstream can reach NDs if he wants to. We remember, Nicolas has no 2001:768:1800::/40 to filter out, because there is no such prefix to filter. He announces the complete Cybernet prefix (2001:768::/32) to his downstream and is attracting traffic to Cybernet into his AS. There he dumps packets to Christian. The difference is easily visable if you look from the downstream's point of view. Christian says "I have no information how to reach 3ffe:4013::/32, don't route this prefix to me". Nicolas says "Yes, I can reach 2001:768::/32 (and that means _the_ _whole_ 2001:768::/32), just give it to me" and then dumps traffic to parts of this prefix. You see the difference? > Moreover, the Ipv6-FR project is not a hoax ;) Ndsoftware help ipv6 to > be developped in France, as you can see it in this news from an > important Data Center in France (Paris) Great, just one more advertising a nonexistant exchange point. I'm gonna shoot myself tomorrow, I'm just too tired right now, okay? TeleCity would probably announce that their cleaning personel found a lost screw in the datacenter if it would keep them in the news. -- bye bye Bernhard From michel@arneill-py.sacramento.ca.us Wed Nov 20 01:28:37 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 19 Nov 2002 17:28:37 -0800 Subject: [6bone] IETF-55 meeting Message-ID: <2B81403386729140A3A899A8B39B046405E496@server2000> 6boners, Some generic comments about the meeting format: Was in a small room, focused audience (something like a fourth of the audience were actual pTLAs. Was less formal than usual. I don't know about you, but I liked this format, which is close than what we have been doing in ipv6mh as well. Comments welcomed. Here are the links to the slides I presented today. http://arneill-py.sacramento.ca.us/ipv6mh/ietf55ilj.ppt http://arneill-py.sacramento.ca.us/ipv6mh/ietf55ilj.pdf Michel. From navaneethams@huawei.com Wed Nov 20 03:19:52 2002 From: navaneethams@huawei.com (navaneetham) Date: Wed, 20 Nov 2002 11:19:52 +0800 Subject: [6bone] why there is no checksum in IPv6 header? In-Reply-To: Message-ID: Hi, what is the reason IPv6 doesn't have checksum in it's header? if header corrupted how this situation will handle by IPv6 router? Thanks, Navaneetham From itojun@iijlab.net Wed Nov 20 03:50:25 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Wed, 20 Nov 2002 12:50:25 +0900 (JST) Subject: [6bone] Fw: [IETF55] 6bone meeting Message-ID: <20021120035025.23E6C4B22@coconut.itojun.org> --NextPart-20021120125017-1146400 Content-Type: Message/Rfc822 Return-Path: itojun@itojun.org Delivery-Date: Wed Nov 20 03:27:06 2002 Return-Path: Delivered-To: itojun@coconut.itojun.org To: wide@wide.ad.jp Subject: [IETF55] 6bone meeting X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Wed, 20 Nov 2002 03:00:25 +0900 Sender: itojun@itojun.org Message-Id: <20021119180025.9D2667B1@starfruit.itojun.org> X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org pekka - 6bone mess scope of the document, background introduction to problems in 6bone focus to routing problem required reading for any 6bone/sTLA sit informational/bcp-like document some thoughts on solutions not perfect or fine-tuned, but enough to give some ideas does not give any final advaice background ipv6 is globally useless due to bad connectivity problems with 6bone large number of BGP peers scaling problems, arms race you can only get good connectivity through 50+ peers? long tunnels instability AS path length as a metric loses its meaning old hardware, buggy software route withdrawal running transit service on old hardwrae or slow connection pTLA a sa hobby (non-ISP's having pTLAs pTLA's having not enough experience with "big ISP business" want to try bigger shoes than they're capable of full transit to everybody traffic does not go via sane paths worst problem reqeuirements for obtaining a pTLA too easy to get a pTLA and start toying alternatives how to reach wait for real ipv6 transit providers/isps could take long big problem of "walled gardens" devise some hacks to bgp apth selection mechanisms to take tunnels etc. into account doesn't seem like the right solution create some (partial) hierarchy and control transit no automatic transit-for-all try to create islands bigger than one as to be significant continue as before forces everyone to participate in the "arms race" narten: clarify "islands" and "need transit providers" ?: US, it's all about money so big ISPs do not start ipv6 services... pTLA/sTLA are single network should we separate them or not? pekka: transit should only made by real "transit" provider ?: which is worse, long tunnel, or transit everywhere? both long tunnel is worse it is difficult to restrict bad tunnels from coming up it is too easy to become pTLA it's all about money, serious operation = money BGP policies should fix it? cmetz: generic problem for overlayed network. chicken-and-egg situation 6bone was started as playground, production network should be separated need content amount of non-diagnostic traffic we need to use it daily we need to shout if there's problem, to get things fixed tag routes with BGP attributes? people using BGP without BGP knowledge guidelines for connecting organizations end-sites ask your isp for v6 "create the market demand" connect as close topologically as you can small/medium-sized isp w/ stla/ptla too small to be globally significant, only in a region lots of tunnels for just them is a waste create some "islands" and connect these globally try to find transit providers change from full transit to mostly pure peering kill "long tunnels" especially if used for full transit real transit providers support v6, if not in every router, at least partially connect to other real transit networks relationship with rfc2772, how to go forward quick summary create hierarchy to be globally significant transit should work together to connect only proper sites prefer local connections, disallow transit how to go forward? aim for bcp/informational, for both 6bone/RIR space owners? develop rules further, or is that for 2772bis? 2772bis rules for 6bone address space owners only could be useful for rir space owners too, of course should not go too deep into the background - only reference 6bone-mess? === 2772 additions how should we change pTLA requirements? who got pTLAs JUSt to get around multi-homing problem? should we revoke bad pTLAs? how can we motivate better performance of 6bone? need to make this draft as explicit as possible, so the newbie can make this work general comment: not trying to make 6bone "production" but to try to get pepole to limit the scope of how they break it scope of document extended to rir space prefix-based multicast more defined increase required registry information better wording on confusing parts more explicit text surrounding filtering of 6bone prefix must provide isp-like service - must be isp? must have valid public ASN must actually advertise the pTLA creation of 6bone stereering group that can enforce rules specified with pTLAs add SLA-like parameters our must try to actually fix a problem that one has keep latency down, response time to problem, ... should this draft go to a working group? pekka: should check current pTLA holders as well. kessens: important to see what we can do to raise quality of applicants rockell: how many of you are IPv6 full-time? kessens: interpretation of rules - part of trouble. pekka: need clear policy and implement it classify by bandwidth? (1) be more strict, like registry? (2) to emulate realworld problem, we need 6bone narten: hierarchical model is a pipe dream pekka: hierarchy in connectivity, not address allocation kessens: be realistic. === LIR what is default free zone? ipv4 dfz: subset of routers that do not have a default route and do not receive a full routing table from a single peer assembly of tier-1 isp dfz and dfz's routing table routing table beyond the dfz's boundaries what is ipv6 dfz? - no transit provider, no tier 1, so no ipv6 dfz three possible scenarios 1. centralized backbone, arpanet/nsfnet style, unlikely 2. competing but interconnected backbones. this is the current tier-1 system. likely. 3. no major backbone but large scale direct interconnection between smaller networks. is this a realistic possibility? (timeout) --NextPart-20021120125017-1146400-- From stansley@microsoft.com Wed Nov 20 04:03:55 2002 From: stansley@microsoft.com (Stewart Tansley) Date: Tue, 19 Nov 2002 20:03:55 -0800 Subject: [6bone] why there is no checksum in IPv6 header? Message-ID: <240659DFBDD99C4299EF7483EAD70F24DB0CE4@RED-MSG-01.redmond.corp.microsoft.com> Speed. You likely do a checksum at layer 2 and layer 4, so why do another. If the header is corrupted, the packet is dropped. Most books explain this rationale. Stewart Tansley Program Manager http://www.microsoft.com/ipv6/ > -----Original Message----- > From: navaneetham [mailto:navaneethams@huawei.com] > Sent: Tuesday, November 19, 2002 7:20 PM > To: 6bone@mailman.isi.edu > Subject: [6bone] why there is no checksum in IPv6 header? > > > Hi, > > what is the reason IPv6 doesn't have checksum in it's > header? if header corrupted how this situation will handle by > IPv6 router? > > > Thanks, > Navaneetham > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone > From navaneethams@huawei.com Wed Nov 20 04:40:41 2002 From: navaneethams@huawei.com (navaneetham) Date: Wed, 20 Nov 2002 12:40:41 +0800 Subject: [6bone] why there is no checksum in IPv6 header? In-Reply-To: <240659DFBDD99C4299EF7483EAD70F24DB0CE4@RED-MSG-01.redmond.corp.microsoft.com> Message-ID: I got your point stewart. the reason why IPv4 has header checksum is, there may be a situation layer 2 may not have checksum (am I right?). did the same situation never happen or what in IPv6? how to handle this? Thanks&Regards, Navaneetham -----Original Message----- From: Stewart Tansley [mailto:stansley@microsoft.com] Sent: Wednesday, November 20, 2002 12:04 PM To: navaneetham Cc: 6bone@mailman.isi.edu Subject: RE: [6bone] why there is no checksum in IPv6 header? Speed. You likely do a checksum at layer 2 and layer 4, so why do another. If the header is corrupted, the packet is dropped. Most books explain this rationale. Stewart Tansley Program Manager http://www.microsoft.com/ipv6/ > -----Original Message----- > From: navaneetham [mailto:navaneethams@huawei.com] > Sent: Tuesday, November 19, 2002 7:20 PM > To: 6bone@mailman.isi.edu > Subject: [6bone] why there is no checksum in IPv6 header? > > > Hi, > > what is the reason IPv6 doesn't have checksum in it's > header? if header corrupted how this situation will handle by > IPv6 router? > > > Thanks, > Navaneetham > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone > From jbartas@iniche.com Wed Nov 20 05:26:25 2002 From: jbartas@iniche.com (John Bartas) Date: Tue, 19 Nov 2002 21:26:25 -0800 Subject: [6bone] why there is no checksum in IPv6 header? References: Message-ID: <3DDB1D01.417FEEC1@iniche.com> Hi navaneetham, IPv6 mandates that the upper layer protocols perform a standard "pseudo sum" of the IP header's key fields (addresses and length) and fold the value into the upper layer sum. IPv4 only did this for TCP and UDP, and thus has the somewhat redundant IP level sum. This saves some CPU cycles assembling and verifying packets, although as you point out it means routers have no easy way to detect corrupt IP headers. I'll most "high speed" routers today don't check the header sums anyway. -JB- navaneetham wrote: > > Hi, > > what is the reason IPv6 doesn't have checksum in it's header? if header > corrupted how this situation will handle by IPv6 router? > > Thanks, > Navaneetham > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone -- -JB- ############################################################# H (==)o(==) H John Bartas - Main Propeller head _I_ H InterNiche Technologies Inc. (408) 257-8014 x219 / \ H 1340 S. DeAnza Blvd. Suite 102 ----- H San Jose CA 95129 O O H jbartas@iniche.com " H www.iniche.com \___/ H From basit@basit.cc Wed Nov 20 06:36:56 2002 From: basit@basit.cc (Abdul Basit) Date: Wed, 20 Nov 2002 00:36:56 -0600 (CST) Subject: [6bone] why there is no checksum in IPv6 header? In-Reply-To: Message-ID: <20021120003508.P10536-100000@wireless.cs.twsu.edu> Well i suppose, it is not required to check checksum at each layer provided the fact that data link / media access layer already provide checksum errors. The reason, it was removed is obvious, that is to improve routing efficiency (minimize the cost of header processing). - basit On Wed, 20 Nov 2002, navaneetham wrote: > Hi, > > what is the reason IPv6 doesn't have checksum in it's header? if header > corrupted how this situation will handle by IPv6 router? > > > Thanks, > Navaneetham From cliff@oisec.net Wed Nov 20 07:27:15 2002 From: cliff@oisec.net (Cliff Albert) Date: Wed, 20 Nov 2002 08:27:15 +0100 Subject: [6bone] why there is no checksum in IPv6 header? In-Reply-To: References: Message-ID: <20021120072715.GA26794@oisec.net> On Wed, Nov 20, 2002 at 11:19:52AM +0800, navaneetham wrote: > what is the reason IPv6 doesn't have checksum in it's header? if header > corrupted how this situation will handle by IPv6 router? The IPv6 router has nothing to do anymore with checksums, they are all handled in upper layers, so that the router does not have to recalculate checksums for packets it handles. The checksum will be checked by the end host and this host will initiate resend mechanisms. If I recall correctly it has been done to reduce router CPU load. -- Cliff Albert | RIPE: CA3348-RIPE | http://oisec.net/ cliff@oisec.net | 6BONE: CA2-6BONE | PGP Fingerprint = 9ED4 1372 5053 937E F59D B35F 06A1 CC43 9A9B 1C5A From hans.goes@wcom.com Wed Nov 20 07:28:04 2002 From: hans.goes@wcom.com (Hans Goes) Date: Wed, 20 Nov 2002 07:28:04 +0000 (GMT) Subject: [6bone] Euronet Internet Message-ID: Hi, I'm trying to reach some people at Euronet Internet in Belgium but they don't reply to email. Does anyone of you have additional contact which are not in the "euronet-be" object ? Euronet NL doesn't have access to the ipv6 box in Brussels. Thanks, Hans Goes WorldCom EMEA Network Operations Joan Muyskenweg 24 1096 CJ Amsterdam Tel: +31 20 7112428 (Fax: 2455) http://www.wcom.com/nl/ From pim@ipng.nl Wed Nov 20 08:49:32 2002 From: pim@ipng.nl (Pim van Pelt) Date: Wed, 20 Nov 2002 09:49:32 +0100 Subject: [6bone] why there is no checksum in IPv6 header? In-Reply-To: References: Message-ID: <20021120084932.GB17344@bfib.colo.bit.nl> On Wed, Nov 20, 2002 at 11:19:52AM +0800, navaneetham wrote: | Hi, | | what is the reason IPv6 doesn't have checksum in it's header? if header | corrupted how this situation will handle by IPv6 router? Because the checksum of the IPv4 header has to be recalculated each time the packet passes a router. All routers decrement the TTL (in IPv6, it's called Hop Count) by one, which changes the contents of the header. It is believed that there are not that many transmission failures these days. In the (unlikely!) event of a datagram corruption, the layer2 checksumming will probably take care of things. If it does not, the router will simply forward the datagram to an erroneous host, which will then in turn disregard it. Due to the low amount of header fields in IPv6, there's not much that can go wrong, except for the source/destination address mutilization. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From mohacsi@niif.hu Wed Nov 20 09:01:26 2002 From: mohacsi@niif.hu (Janos Mohacsi) Date: Wed, 20 Nov 2002 10:01:26 +0100 (CET) Subject: [6bone] why there is no checksum in IPv6 header? In-Reply-To: Message-ID: <20021120095140.G29359-100000@evil.ki.iif.hu> On Wed, 20 Nov 2002, navaneetham wrote: > Hi, > > what is the reason IPv6 doesn't have checksum in it's header? if header > corrupted how this situation will handle by IPv6 router? What is the reason to get the IPv6 packet get corrupted? 1. Usually It can happened in the lower layer, where much better error detection and even correction mechanisms exist to prevent such a corruption. 2. If some accidental thing happen to get IPv6 packet corrupted, then the upper layer should handle the problem. With IPv6, the checksum is mandatory for TCP (of course) and UDP (it was not the case for IPv4, to speed up e.g. the NFS). 3. If somebody sending corrupted IPv6 packets, then the end system should detect and drop it. However it might have some negative impact on the performance of the end system receiving deliberately corrupted IPv6 packets. New form of DoS? It was a engineering decision to off-load the routers from recomputing the IP checksum everytime they forward a packet. Best Regards, Janos Mohacsi > > > Thanks, > Navaneetham > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From basit@basit.cc Wed Nov 20 11:52:35 2002 From: basit@basit.cc (Abdul Basit) Date: Wed, 20 Nov 2002 05:52:35 -0600 (CST) Subject: [6bone] ipv6 traffic generator Message-ID: <20021120055159.V82390-100000@wireless.cs.twsu.edu> hello, are there any decent ipv6 traffic generators , free one's ofcourse ? take care - basit From pasky@pasky.ji.cz Wed Nov 20 12:36:07 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Wed, 20 Nov 2002 13:36:07 +0100 Subject: [6bone] Blackholing on 6bone (possible RFC 2772-bis bit?) In-Reply-To: <001601c28fef$501081d0$fd04a80a@alpha> References: <001601c28fef$501081d0$fd04a80a@alpha> Message-ID: <20021120123607.GQ22026@pasky.ji.cz> Dear diary, on Tue, Nov 19, 2002 at 06:15:51PM CET, I got a letter, where Christian Nickel told me, that... > > I'm glad to announce that NDSoftware (AS25358) has setup filters for > > drop any packets from and to 2001:658:217::/48, 2001:618:B::/48, > > 2001:768:1800::/40. > > > > >From your website (http://www.tdoi.org): > > "Our Autonomous System does not accept prefix 3ffe:4013::/32. > > Any route via AS25358 will be removed. > > You cannot reach any prefix routed via AS25358!" > > > > It's too funny. > > > > You don't have an Autonomous System, you have a private ASN with 2 /48 > > and 1 /40 for play. I believe that introducing such a practice to 6bone is potentially very dangerous; it can possibly devolve to endless revenges chain and further irresponsible behaviour affecting reachability of nodes over the whole IPv6 world, further harming the reputation and transition to IPv6. This is no longer even 6bone itself issue, since the blackholed host is from the production RIPE's space. This practice can thus help the argumentation for isolation of the 6bone prefixes. There's a question if pTLA operators should fall into revenge to end sites (even connected by other pTLAs). It is private decision of the end user TDOI to filter announcements made by other ASN and it is private decision of NDSOFTWARE to filter TDOI _for ourselves_. But it affects the whole 6bone routing if one pTLA is effectively blackholing some arbitrary prefix for not well-posed and well-announced reasons. Thus, it would be probably extremely desirable if (choose one): a) NDSOFTWARE terminated this filtering b) NDSOFTWARE filtered this prefix only for its customers, not peers c) NDSOFTWARE did not announce the prefix (2001:768::/32) to its peers d) NDSOFTWARE peers re-thought the peering policy and were careful about accepting full transit from NDSOFTWARE e) 6bone community was careful about prefixes it's receiving which have NDSOFTWARE's ASN in their AS path I basically believe that leaving this uncommented can settle dangerous precedent for the future, thus this case should be carefully dealt with. Note that I have no positive relation with TDOI and I try hard to have no negative relation with NDSOFTWARE. Further, I think that maybe it would be desirable to add some tiny paragraph about this to RFC 2772. Kind of: "pTLA providers SHOULD NOT filter traffic destinating at arbitrary prefixes while still announcing the prefix, effectively blackholing the prefix, unless it properly announces and reasonates such action and is ready to re-think the measure if it met disagreement in the 6bone community." Any comments welcomed! :-) "Oh no, another policial thread," I know, but I think that these issues should be discussed and solved somehow. Kind regards, -- Petr "Pasky" Baudis . weapon, n.: An index of the lack of development of a culture. . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From Sascha Bielski Wed Nov 20 13:32:38 2002 From: Sascha Bielski (Sascha Bielski) Date: Wed, 20 Nov 2002 14:32:38 +0100 Subject: [6bone] Blackholing on 6bone (possible RFC 2772-bis bit?) In-Reply-To: <20021120123607.GQ22026@pasky.ji.cz> References: <001601c28fef$501081d0$fd04a80a@alpha> <20021120123607.GQ22026@pasky.ji.cz> Message-ID: <188839932281.20021120143238@rdns.de> Dear Petr Baudis, >> > I'm glad to announce that NDSoftware (AS25358) has setup filters for >> > drop any packets from and to 2001:658:217::/48, 2001:618:B::/48, >> > 2001:768:1800::/40. [19:04:54] _DrAGON_ is too lame :) we don't have setup filters, i have just sent the mail for get a reaction from him That was yesterday. ;-) And after my mail yesterday mister TDOI removed the peering to me. wow, what a nice reason. troll ;-) > Further, I think that maybe it would be desirable to add some tiny paragraph > about this to RFC 2772. Kind of: "pTLA providers SHOULD NOT filter traffic > destinating at arbitrary prefixes while still announcing the prefix, > effectively blackholing the prefix, unless it properly announces and reasonates > such action and is ready to re-think the measure if it met disagreement in the > 6bone community." I agree. Remember my mail about the test-time. Still no useful comments. Go on! ;-) -- best regards, Sascha Bielski mailto:sb@rdns.de xs26.net German Coordination phone: +49 (0) 174 / 432 93 76 email: sb@rdns.de From navaneethams@huawei.com Wed Nov 20 13:33:47 2002 From: navaneethams@huawei.com (navaneetham) Date: Wed, 20 Nov 2002 21:33:47 +0800 Subject: [6bone] why there is no checksum in IPv6 header? In-Reply-To: <20021120095140.G29359-100000@evil.ki.iif.hu> Message-ID: what is the reason IPv6 requires that every link in the internet have an MTU of 1280 octets or greater? what is the benefit of having this restriction!!? Navaneetham From navaneethams@huawei.com Wed Nov 20 13:34:56 2002 From: navaneethams@huawei.com (navaneetham) Date: Wed, 20 Nov 2002 21:34:56 +0800 Subject: [6bone] MTU (Min : 1280) restriction in IPv6 In-Reply-To: Message-ID: what is the reason IPv6 requires that every link in the internet have an MTU of 1280 octets or greater? what is the benefit of having this restriction!!? Navaneetham From nicolas.deffayet@ndsoftware.net Wed Nov 20 13:43:59 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 20 Nov 2002 14:43:59 +0100 Subject: [6bone] Re: Blackholing on 6bone (possible RFC 2772-bis bit?) In-Reply-To: <20021120123607.GQ22026@pasky.ji.cz> References: <001601c28fef$501081d0$fd04a80a@alpha> <20021120123607.GQ22026@pasky.ji.cz> Message-ID: <1037799838.26581.1634.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-11-20 at 13:36, Petr Baudis wrote: > Dear diary, on Tue, Nov 19, 2002 at 06:15:51PM CET, I got a letter, > where Christian Nickel told me, that... > > > I'm glad to announce that NDSoftware (AS25358) has setup filters for > > > drop any packets from and to 2001:658:217::/48, 2001:618:B::/48, > > > 2001:768:1800::/40. > > > > > > >From your website (http://www.tdoi.org): > > > "Our Autonomous System does not accept prefix 3ffe:4013::/32. > > > Any route via AS25358 will be removed. > > > You cannot reach any prefix routed via AS25358!" > > > > > > It's too funny. > > > > > > You don't have an Autonomous System, you have a private ASN with 2 /48 > > > and 1 /40 for play. > > > I believe that introducing such a practice to 6bone is potentially very > dangerous; it can possibly devolve to endless revenges chain and further > irresponsible behaviour affecting reachability of nodes over the whole IPv6 > world, further harming the reputation and transition to IPv6. This is no longer > even 6bone itself issue, since the blackholed host is from the production > RIPE's space. This practice can thus help the argumentation for isolation of > the 6bone prefixes. > > There's a question if pTLA operators should fall into revenge to end sites > (even connected by other pTLAs). It is private decision of the end user TDOI to > filter announcements made by other ASN and it is private decision of NDSOFTWARE > to filter TDOI _for ourselves_. But it affects the whole 6bone routing if one > pTLA is effectively blackholing some arbitrary prefix for not well-posed and > well-announced reasons. Thus, it would be probably extremely desirable if > (choose one): > > a) NDSOFTWARE terminated this filtering > b) NDSOFTWARE filtered this prefix only for its customers, not peers > c) NDSOFTWARE did not announce the prefix (2001:768::/32) to its peers > d) NDSOFTWARE peers re-thought the peering policy and were careful about > accepting full transit from NDSOFTWARE > e) 6bone community was careful about prefixes it's receiving which have > NDSOFTWARE's ASN in their AS path > > I basically believe that leaving this uncommented can settle dangerous > precedent for the future, thus this case should be carefully dealt with. Note > that I have no positive relation with TDOI and I try hard to have no negative > relation with NDSOFTWARE. Christian is an inmensly irritating clueless kiddie who wants to impress other 6bone / ipv6 users. We don't have setup any filters ! My email was only for have a reaction of Christian about him filtering. I don't appreciate his message on his website about our AS and pTLA filtering. Before send my email to Christian, i have checked the reality of him filtering but Christian is too lame and don't have check the reality of our filtering before send him email to 6bone mailing-list. We will NEVER do packet filtering and we will NEVER filter valid ASN and valid pTLA/sTLA. We manage our network professionnaly, we will never do filtering for fun. > Further, I think that maybe it would be desirable to add some tiny paragraph > about this to RFC 2772. Kind of: "pTLA providers SHOULD NOT filter traffic > destinating at arbitrary prefixes while still announcing the prefix, > effectively blackholing the prefix, unless it properly announces and reasonates > such action and is ready to re-think the measure if it met disagreement in the > 6bone community." I support this. I think that "pTLA providers SHOULD NOT filter traffic, valid ASN and valid pTLA/sTLA" is better. Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From mohacsi@niif.hu Wed Nov 20 13:46:38 2002 From: mohacsi@niif.hu (Janos Mohacsi) Date: Wed, 20 Nov 2002 14:46:38 +0100 (CET) Subject: [6bone] ipv6 traffic generator In-Reply-To: <20021120055159.V82390-100000@wireless.cs.twsu.edu> Message-ID: <20021120144512.M29359-100000@evil.ki.iif.hu> Hi, On Wed, 20 Nov 2002, Abdul Basit wrote: > > hello, > > are there any decent ipv6 traffic generators , > free one's ofcourse ? Try mgen6, that is a fairly good basic one: http://matrix.it.uc3m.es/~long/software/mgen6/mgen6/ Janos > > take care > - basit > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From pim@ipng.nl Wed Nov 20 13:53:24 2002 From: pim@ipng.nl (Pim van Pelt) Date: Wed, 20 Nov 2002 14:53:24 +0100 Subject: [6bone] Euronet Internet In-Reply-To: References: Message-ID: <20021120135324.GA12438@bfib.colo.bit.nl> On Wed, Nov 20, 2002 at 07:28:04AM +0000, Hans Goes wrote: | Hi, | | I'm trying to reach some people at Euronet Internet in Belgium but they | don't reply to email. | | Does anyone of you have additional contact which are not in the | "euronet-be" object ? Hans, Francois Baligant groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From jeroen@unfix.org Wed Nov 20 14:41:25 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Wed, 20 Nov 2002 15:41:25 +0100 Subject: [6bone] ipv6 traffic generator In-Reply-To: <20021120055159.V82390-100000@wireless.cs.twsu.edu> Message-ID: <002f01c290a2$e76b5d30$210d640a@unfix.org> Abdul Basit wrote: > hello, > > are there any decent ipv6 traffic generators , > free one's ofcourse ? As you didn't mention the reason for generating traffic I assume that you want to test IPv6 throughput. A good tool for this is IPerf as found on: http://dast.nlanr.net/Projects/Iperf/ Good thing about Iperf is that it's IPv4 and IPv6 capable and as such one can test differences in throughput between 4 and 6. One will notice that unfortunatly most of the time IPv6 is at loss due to the current 6bone mess. When this has been cleared out, and there are a couple of groups pondering about this I know from testing on native links that IPv6 will have a real benefit over IPv4 when checking throughput. Greets, Jeroen From basit@basit.cc Wed Nov 20 16:18:54 2002 From: basit@basit.cc (Abdul Basit) Date: Wed, 20 Nov 2002 10:18:54 -0600 (CST) Subject: [6bone] ipv6 traffic generator In-Reply-To: <002f01c290a2$e76b5d30$210d640a@unfix.org> Message-ID: <20021120100731.P83610-100000@wireless.cs.twsu.edu> Hello i checked on native links, i found it is reasonably better than normal ipv4 though. I was using iperf actually, but i was not able to find any tool that can generate graphs based on iperf logs. can you point out some? I am using tcptrace to analyze tcpdumps for now to generate xplot/graphs ( but the problem is it can handle only tcp traffic). for generating ipv6 tcp traffic i use sendip but the problem with sendip is, it can't generate any application level packet (say http). Can you point me some ipv6 traffic generators that supports extensive features of ipv6, like mobile ipv6 binding update time , fast handovers etc? and generate graphs based on that info? NS2 (Network simulator ) doesn't support many features of Mobile IPv4 even, MOBIWAN is hard to setup, though i set MOBIWAN correctly but i am not able now to get trgraph read ns2 trace files generated by MOBIWAN? Kame MIPv6 support isn't properly documented, USAGI has mobile ipv6 experimental support also LINA/LIN6 isn't well-documented ? Where to look ? are those all standards just exists in theory ? Don't we have some elegant approach ? instead of all softwares scattered around to support bits of things ? I beleive we need to have a project started on this ( like developing a IPv6 simulator supporting every bit of information specified in most recent rfc's). - basit graduate student wichita state univ. On Wed, 20 Nov 2002, Jeroen Massar wrote: > Abdul Basit wrote: > > > hello, > > > > are there any decent ipv6 traffic generators , > > free one's ofcourse ? > > As you didn't mention the reason for generating traffic > I assume that you want to test IPv6 throughput. > A good tool for this is IPerf as found on: > http://dast.nlanr.net/Projects/Iperf/ > > Good thing about Iperf is that it's IPv4 and IPv6 capable > and as such one can test differences in throughput between 4 and 6. > One will notice that unfortunatly most of the time IPv6 is at loss > due to the current 6bone mess. When this has been cleared out, and > there are a couple of groups pondering about this I know from testing > on native links that IPv6 will have a real benefit over IPv4 when > checking throughput. > > Greets, > Jeroen > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From berni@birkenwald.de Wed Nov 20 16:31:48 2002 From: berni@birkenwald.de (Bernhard Schmidt) Date: Wed, 20 Nov 2002 17:31:48 +0100 Subject: [6bone] Re: Blackholing on 6bone (possible RFC 2772-bis bit?) In-Reply-To: <1037799838.26581.1634.camel@wks1.fr.corp.ndsoftware.com> References: <001601c28fef$501081d0$fd04a80a@alpha> <20021120123607.GQ22026@pasky.ji.cz> <1037799838.26581.1634.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021120163148.GA92010@thor.birkenwald.de> On Wed, Nov 20, 2002 at 02:43:59PM +0100, Nicolas DEFFAYET wrote: > I think that "pTLA providers SHOULD NOT filter traffic, valid ASN and > valid pTLA/sTLA" is better. Nope, the first version was better. It's everyones own decision which prefixes/ASNs to accept in his own AS, as long as this filtering does not affect the routing of other ASes. -- bye bye Bernhard From barce@frlp.utn.edu.ar Wed Nov 20 16:48:03 2002 From: barce@frlp.utn.edu.ar (Carlos A. Barcenilla) Date: Wed, 20 Nov 2002 13:48:03 -0300 Subject: [6bone] MTU (Min : 1280) restriction in IPv6 References: Message-ID: <3DDBBCC3.7020309@frlp.utn.edu.ar> Hi IPv6 routers are not allowed to fragment IPv6 packets. Senders must fragment packets, so they need to know the Path MTU for the destination address. Path MTU discovery is needed fot that. If a node does not want to implement Path MTU Discovery it can assume that every Path MTU has 1280 bytes. Carlos. navaneetham wrote: > what is the reason IPv6 requires that every link in the internet have an >MTU of 1280 octets or greater? > > what is the benefit of having this restriction!!? > > >Navaneetham > >_______________________________________________ >6bone mailing list >6bone@mailman.isi.edu >http://mailman.isi.edu/mailman/listinfo/6bone > > From RJorgensen@upctechnology.com Wed Nov 20 18:39:01 2002 From: RJorgensen@upctechnology.com (Jorgensen, Roger) Date: Wed, 20 Nov 2002 19:39:01 +0100 Subject: [6bone] RFC 2772 input from RIR space holder Message-ID: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> Hi, Going to reply to Robert's mail that never got the attention it deserved. It is very important to understand why RIR space holders care about RFC 2772. We make living out of selling/providing services over Internet, we are totaly depended on what people call production quality or reliable routing. It's not just a word for us, it's our life as a provider we're talking about. We can assume that most of the services that will be important from a business perspective will be using RIR space. Think we also can safely assume that RIR space are for production services (as said above), and 6bone space used for experimental/learning/testing purpose. This isn't just the view of one single sTLA holder, it's a view I know is shared by many others. How to create a stable IPv6 network are The Focus for many big ISP's with sTLA right now. There are work in progress to create guidelines and later I guess it might be an official document covering the routing issue in RIR space. We will sort ourself out...the issue is 6bone routing. We do NOT want 6bone to have ANY impact on our business at all. That's pretty much the bottom line. Robert outlined one way to gain this in his mail (see end of mail), the following part are a suggestion from me, it's build on the frame Robert outlined. --- to keep it simple: * 6bone sites can announce each other their pTLA route within the 3ffe::/16 cloud including _one_ default 2001::/16 route. Then we need a extra addon to this to avoid causing never ending loops: * A site can ONLY announce the default RIR prefix to other peers IF they have the more specific RIR prefixes in their table. example, I'm a pTLA with no connection to RIR space and should have no RIR prefixes in my table, in this cause I can NOT provide transit to RIR space to anyone else than my endusers. Or in other word, I can not provide RIR space transit to other 6bone sites.... The advantage of this: - 6bone/RIR space will become two separate network that can NOT break each other, we (RIR) can guaranty routing easier. - 6bone can do as much experimental stuff as they want to, they can still NOT harm production traffic (production traffic should anyway ALWAYS go over and use RIR space) disadvantage: - it add a bit more complexity to the routing but think what we gain from it are more important. - longer routing in general when you're going RIR <> 6bone space. It basically give us the chance to make a quality production IPv6 network AND still be able to do experimental stuff on 6bone without impact on each other. it also give us (RIR) the chance to guaranty routing in RIR space, or to say it as manager: "we can provide production quality on our IPv6 network" thoughts? --- Roger Jorgensen (rjorgensen@upctechnology.com) System Engineer @ engineering - UPC Technology handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > -----Original Message----- > From: 6bone-admin@mailman.isi.edu > [mailto:6bone-admin@mailman.isi.edu]On > Behalf Of Robert Kiessling > Sent: Saturday, November 16, 2002 4:24 PM > To: Bob Fink > Cc: 6bone@ISI.EDU > Subject: Re: [6bone] RFC2772 rewrite -- bigger scope goals > > > Here is a rather radical proposal: > > Peerings between 6bone sites MUST NOT carry any other > routes apart > from 3FFE and a summary route for 2001/3. > > This achieves a number of goals: > > - it provides a clear distinction between the experimental > part from the rest of > the IPv6 world > > - interconnections between 6bone and the rest of the IPv6 > world can still > be numerous and reliable > > - existing services in the 3FFE space can be accessed from > everywhere, > noone is cut off > > - cost-free trial implementation is still possible, but > transition to RIR space > is encouraged > > - since RIR sites can filter RIR space from peerings with 6bone sites, > BGP problems from 6bone sites will not affect the global network > > and last but not least > > - it's a very simple, verifyable criterion > > Of course, all is not gold, so there are some drawbacks: > > - 6bone sites will no longer see 2001 routes, so they will need to do > "closest exit" routing to the nearest RIR site. > > - peerings between dual (RIR & 6bone) sites will not carry 2001 space > > - propably others I haven't thought of > > Robert > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > begin 600 winmail.dat M>)\^(BH2`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<` M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06``P`.````T@<+`!0` M$P`G``$``P`V`0$@@`,`#@```-('"P`4`!,`*P`H``,`80$!"8`!`"$````V M,$-&.#,Y-44V,T%!130R0CDP,S1",#8W04,T1#`U-P`L!P$$@`$`)0```%)& M0R`R-SES]&Q$VH(SN`5!`0,!]_\*@`*D`^0'$P*`#_,`4`16/PA5![(1)0Y1`P$"`&-H MX0K`,@@`8@20="<$ M(`#`C0,1=!/@!4!N9782@L%)) M4B#2`B1*L`2@4D" M,`21%"#]'15W(/$FT1Y``9`>H0$`_G`)\`$`).`A@24`(`$N$'YO"U`@\":P M*D`N\`-@9+,:T"%C<74'0"&P>1TD_P6Q&"`I0`&@+T$#8"H3BJ)4??+3,SXATD+\DK1R@UH4%`MRK@ M)O(@4"DT0"3"-@;@_R`P0J4S,"Y1,^$=)`[`/8'W!W$",`=`+R]`"L`#`"IQ M]PZP)*`>`G`(<".@%!`G[.=`(00@!`!N)S,%(-(I8!\'T2GQ1J,>`2]!1),+_"V`L02+`)_5:0#U"(;`?@.]7`SM1`Y$I\&8-X`#_ M5-%(@B:@*](>`R#A,@4=).\$`0I06-(_*"`HP3L#0-#_`"`THBHA3/$WD6+@ M(-)@)7YS'21&A#('*,%=\`>P3WY4)/`CXD:$'D$3X#X10?Q.62-R`-`IT5U! M"'`=)/\\]R`!+X$BL$`@(``?82J@_Q0@,,`?@!K05H`@T@;@`D#_/*%:DB*P M'P0PY2LV<+<1_12W(#H/M+8A^3*!00(/`N(2GB'Y+_1A`= M)"#2`A`J0$_@2<,*P,02D0'H!<8@"0ZR.0+T`Z'20J1G8AL`>1 M_3AC;C+@)%!"X4D`:G%1,_4@PFD%P'!6LR`E]&H5\MX69AS'5L!4`!T#`Q?Q1]4_]V2U2! M+I$@\"`P+E$S<`[!^W4`(0!D7?!MX1Y0;@,>0?]FL!WP).`FL#[$(#0N(1X" M>Q>P+R!S>==-\'K".%-/_$Y,9Q![9R#2@-8E0FGA?5V`>!XR?$0N$"2!?E9) M_D8@PAZP9J,@T@1@)M$]LO\&D`W@BDD'D7WT?-%2PW9+ST?&=1`O,31`22<\ MLGT#_U93,N!><7MP/=*$E$)Y)-'_4$`(8'/Q9J.2P25!0Y:.N/YM'K$QLC1! M;>6%TE,!.%/_98(U]1XP=0``@20#)4(=)/]"M(5"40!&HBHPF$$?X9;3]RXA M1T%1#"Q_X2T,><\X2"R0$,ZPUHA"W+_?F4\@[LR)M&- M$!*!K&98X7)0(#!U``,@=R4`@S&;D'4VHB"0/N8\_CY&>J*/3X% ML/YG/@)4\2#2$]&)4QY0*/-_,W`P=2^Z4R(G]5/&9O!$_['D7/,QPAY!95&O M+TSR1G7_5E(G(E_%9T=[^"*PNS)`PO_'YJLTR&RKUQTDPGDE1S1`OP6Q'D%! M0"-A,U$?=4=)"(M$3ABF18OS^]1$6>SRM13Q2+%_W"!"&!Y5Q%S M/]O?=P@(`,(R2H\%L,,A%!`#H"AR:M^FV$!U<#`0!9!H,N`7L'AG>2ZG`;D5 M!K`DH&7=/+!%'A`](1*!0&]1XP33'@*E<%50)X!4X38@1H,MA&!(!""#2RN,SD?\F4`U/6-$L09+X`GXDPA,:_Q1WZ285`[&H!JD[40Q!+%#_ M8C!:U#%V%5^#\0^S*RE]].\']$*T.&)=`F,KD4=3/)+_Z2:&8K906`(T0`$( M,N!&HKN7XBG#9AV?7G'BD"T\@/]O,80@7;)Y@TB#V<-0$LQC_THQQV"70[WR MZ2:9E9-N`0C_2W'@P%Z`2A"D415/I7`]$?]"X3\C>M==@($@!3%">#R#/XN2 M`D.2TDCQXI`M#Y].AR+A>676`%ZB9GE2T_]2(/M1^T#.P/SN\;$L M@IA`_T8A&T%+<9[2MX!.,-8`0-&O44)8--'@=2%D=0!WQT#\8VL-+^1!-"^2 MP<(%;R+_"=(%U3^FL+$T\X.BS30!"-XB?W&80!-QO*(BK%>]!?_+D%1!$W$N MA@H_I7`PQP*6Y[.`ZE&K,B`FQ22K<#2-_P1D1),K2TKY``%2T03E_L#S6Y!F MHFXGOA+=$QDA_.[[:[K]2%]5CU:?5VKI)L4T?V["AN,/L5A[[-[I)E+0=-IP M?R`O[.U`'```0```"4```!21D,@,C`#!``0`` M``L```!22D]21T5.4T5.```#`!E```````,`)@```````P`V```````+`/(0 M`0````,`@!#_____`@%'``$````R````8SU54SMA/2`[<#U#2$5,3$\[;#U. M3$-"0DU3,#,M,#(Q,3(P,3@S.3`Q6BTY,30Q-P````(!^3\!````3P`````` M``#`#A``0````L```!22D]21T5.4T5.```" M`?L_`0```$\`````````W*=`R,!"$!JTN0@`*R_A@@$`````````+T\]0TA% M3$Q/+T]5/4%-4U1%4D1!32]#3CU214-)4$E%3E13+T-./5)*3U)'14Y314X` M`!X`^C\!````$0```$IO`#40`0```#4````\-T-%030P0S!%,3!#-T0T1D)% M,# Message-ID: hi, IPv6 says that host has to maintain pathMTU information for each destination. Consider webserver which is running over IPv6. Many clients will connect to webserver at the same time. Did webserver has to maintain pathMTU information for each client or what? in this case maintaining all the information is burden right? how to handle this? same problem has to address for Binding update list(IP Mobility) also. In this case consider all the clienta are a mobility clients, which is connected to webserver. Thanks, Navaneetham From nicolas.deffayet@ndsoftware.net Thu Nov 21 15:49:58 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 21 Nov 2002 16:49:58 +0100 Subject: [6bone] RFC 2772 input from RIR space holder In-Reply-To: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> Message-ID: <1037893798.26572.7790.camel@wks1.fr.corp.ndsoftware.com> On Wed, 2002-11-20 at 19:39, Jorgensen, Roger wrote: Hi, > Going to reply to Robert's mail that never got the attention it > deserved. It is very important to understand why RIR space > holders care about RFC 2772. > > We make living out of selling/providing services over Internet, > we are totaly depended on what people call production quality > or reliable routing. It's not just a word for us, it's our life > as a provider we're talking about. > We can assume that most of the services that will be important > from a business perspective will be using RIR space. > Think we also can safely assume that RIR space are for > production services (as said above), and 6bone space used for > experimental/learning/testing purpose. A lot of ISP use their sTLA for experimental/learning/testing purpose. > This isn't just the view of one single sTLA holder, it's a view > I know is shared by many others. Many others ? Who are they ? > How to create a stable IPv6 > network are The Focus for many big ISP's with sTLA right now. > There are work in progress to create guidelines and later I > guess it might be an official document covering the routing > issue in RIR space. We will sort ourself out...the issue is > 6bone routing. We do NOT want 6bone to have ANY impact on our > business at all. That's pretty much the bottom line. Robert > outlined one way to gain this in his mail (see end of mail), > the following part are a suggestion from me, it's build on > the frame Robert outlined. The problems (ghost routes, unstability, bad performances,..) are not 6bone specific. This problems are just a pretext for don't have 6bone address in your routing table. This problems must be solved. Circumvent a problem is easy, resolve it is more hard. Currently 6bone and RIR have the same network topology (a lot of tunnels and very little native links) and there is not transit provider, the only difference beetween 6bone and RIR are address type (pTLA/sTLA) in routing table. Now, we will imagine that the 6bone does not exist any more. - There is not transit provider, you exchange a full table with your peers. (no changes with 6bone) - There is a ISP with a old routing software and this ISP generate ghost routes. (no changes with 6bone) - You peer with a lot of tunnel. (no changes with 6bone) The ONLY change will be that you don't have 6bone address in your routing table. > It basically give us the chance to make a quality production IPv6 > network AND still be able to do experimental stuff on 6bone without > impact on each other. it also give us (RIR) the chance to guaranty > routing in RIR space, or to say it as manager: > > "we can provide production quality on our IPv6 network" You will guaranty routing over tunnel ? Tunnels offer bad and random performance. You can own your fiber, control your IPv4 network, but you will have always the tunnel encapsulation. For provide a real production quality, you must have a native IPv6 network without tunnels. Cut 6bone and RIR will be beneficial only if RIR have a lot of native links and very little tunnels. Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From michael@kjorling.com Thu Nov 21 16:30:13 2002 From: michael@kjorling.com (Michael Kjorling) Date: Thu, 21 Nov 2002 17:30:13 +0100 (CET) Subject: [6bone] RFC 2772 input from RIR space holder In-Reply-To: <1037893798.26572.7790.camel@wks1.fr.corp.ndsoftware.com> References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> <1037893798.26572.7790.camel@wks1.fr.corp.ndsoftware.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 21 2002 16:49 +0100, Nicolas DEFFAYET wrote: > > It basically give us the chance to make a quality production IPv6 > > network AND still be able to do experimental stuff on 6bone without > > impact on each other. it also give us (RIR) the chance to guaranty > > routing in RIR space, or to say it as manager: > > > > "we can provide production quality on our IPv6 network" > > You will guaranty routing over tunnel ? > Tunnels offer bad and random performance. > You can own your fiber, control your IPv4 network, but you will have > always the tunnel encapsulation. > > For provide a real production quality, you must have a native IPv6 > network without tunnels. > > Cut 6bone and RIR will be beneficial only if RIR have a lot of native > links and very little tunnels. Sorry Nicolas, I don't see how you are reasoning here. When Richard talks about "our IPv6 network" the way I read it is as in "our native IPv6-on-the-link-layer network". When there are only a few providers that provide IPv6 services, tunnels might be the only option to get IPv6 connectivity _at all_. It is not a great solution, but it certainly is better for those who wish to learn about IPv6 than having no connectivity at all. Actually, the suggestion of creating separate networks for 6bone and RIR space seems pretty reasonable to me. Those who are getting their IPv6 uplink from someone who is running on 6bone space will probably know about that, and as I think it is safe to assume that most commercial sites will be on RIR space, this will prompt a migration from 6bone towards RIR space based on round trip times, and in extension site access times. Plus, it will create a separate network, experimental in nature, where people are able to experiment. If they find out after 15 minutes that they somehow leaked a bad route, well, at least it hasn't affected commercial services. As for those who are running RIR space IPv6 routers, demand that they learn the necessary skills before assigning them the job of handling the IPv6 routers. Who would give someone without adequate knowledge the authority to handle IPv4 routers, and in particular routers facing the Interent? This is no different. Michael Kjörling - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com - Amateur Radio: SMØYBY \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE93QoZKqN7/Ypw4z4RArXiAJ4lHYlFwxGhJuwH4Dfq0FdkYdHPUACfa8Q1 OgmsqQKta3fmrqU9ukIELr0= =xRFQ -----END PGP SIGNATURE----- From pasky@pasky.ji.cz Thu Nov 21 16:47:15 2002 From: pasky@pasky.ji.cz (Petr Baudis) Date: Thu, 21 Nov 2002 17:47:15 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> Message-ID: <20021121164715.GJ25628@pasky.ji.cz> Dear diary, on Wed, Nov 20, 2002 at 07:39:01PM CET, I got a letter, where "Jorgensen, Roger" told me, that... > Hi, Hello, after some internal XS26 survey, Jan Oravec proposed another, potentially much simpler way, how to solve current situation for RIRs. I had some heavy discussion with Roger about this, but I decided to summarize the main points on the mailing list as well. > to keep it simple: > * 6bone sites can announce each other their pTLA route within the > 3ffe::/16 cloud including _one_ default 2001::/16 route. > > Then we need a extra addon to this to avoid causing never ending loops: > * A site can ONLY announce the default RIR prefix to other peers > IF they have the more specific RIR prefixes in their table. > > > example, I'm a pTLA with no connection to RIR space and should have no RIR > prefixes in my table, in this cause I can NOT provide transit to RIR > space to anyone else than my endusers. Or in other word, I can not provide > RIR space transit to other 6bone sites.... > > > The advantage of this: > - 6bone/RIR space will become two separate network that can NOT break > each other, we (RIR) can guaranty routing easier. > - 6bone can do as much experimental stuff as they want to, they can still > NOT harm production traffic (production traffic should anyway ALWAYS > go over and use RIR space) > > disadvantage: > - it add a bit more complexity to the routing but think what we gain > from it are more important. > - longer routing in general when you're going RIR <> 6bone space. > > > It basically give us the chance to make a quality production IPv6 > network AND still be able to do experimental stuff on 6bone without > impact on each other. it also give us (RIR) the chance to guaranty > routing in RIR space, or to say it as manager: > > "we can provide production quality on our IPv6 network" > > > thoughts? Basically, Jan's proposal is like: the distribution of the prefixes does not need to change fundamentally, the only change required is in 6bone -> RIRs connections. In such passages, 6bone sites MUST NOT announce prefix 2001::/16 nor any more specific prefixes matching this prefix, and RIR sites MUST filter any such prefixes. The advantages of this: + 6bone/RIR space will become two separate networks that can NOT break each other, RIR people can guarantee routing easier. + 6bone can do as much experimental stuff as they want to, they can still NOT harm production traffic (production traffic should always ALWAYS go over and use RIR space). + Whole 6bone still gets full RIR prefixes feed (with the original proposal, each pTLA wouild need to have at least one full-transit peering with some sTLA or direct peering with another pTLA which would have it; this would possibly lead to further degenration of the 6bone hiearchy). + The only really required steps are on the RIR side, and the filtering is much less complex; Roger says that RIRs can coordinate themselves, so we can probably take as a working invariant that all RIRs will employ this filtering. + The routing prolonging is not so distinct. The disadvantages: 0 In some cases, the routing can still take a little longer path than now; we can assume that the path will be more stable in many cases, though; we won't be able to do better anyway. ? Roger says that they won't have their prefix "under control", but I fail to see how it matters, if it won't harm their production RIR-RIR routing anymore. ? Roger says that they still won't be able to assure that 6bone sites will receive their prefix correctly; I fail to see a difference from his solution here, though; with his solution, additionally, the 6bone site's pTLA would have to do additional excessive special steps in order to just _receive_ the prefix. What are your proposals, opinions, thoughts, votes and so on? (Note that I believe that it is certainly not desirable to turn this thread into another flamewar about details, professionality, "productionness" of networks and so on. Please desist from such things, and if someone else (with both some specific people and general audience in mind) won't, it would be probably nice not to prolong such flames and thus not to reply to such emails.) Kind regards, -- Petr "Pasky" Baudis . weapon, n.: An index of the lack of development of a culture. . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From gert@space.net Thu Nov 21 17:03:54 2002 From: gert@space.net (Gert Doering) Date: Thu, 21 Nov 2002 18:03:54 +0100 Subject: [6bone] RFC 2772 input from RIR space holder In-Reply-To: <1037893798.26572.7790.camel@wks1.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Thu, Nov 21, 2002 at 04:49:58PM +0100 References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> <1037893798.26572.7790.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021121180353.I15927@Space.Net> Hi, On Thu, Nov 21, 2002 at 04:49:58PM +0100, Nicolas DEFFAYET wrote: > On Wed, 2002-11-20 at 19:39, Jorgensen, Roger wrote: [..] > > This isn't just the view of one single sTLA holder, it's a view > > I know is shared by many others. > > Many others ? > Who are they ? Us, for example. 2001:608::/32. (I usually spend more time on making things work than on making noise on mailing lists, which is why you haven't read that much from me recently) [..] > The problems (ghost routes, unstability, bad performances,..) are not > 6bone specific. > This problems are just a pretext for don't have 6bone address in your > routing table. This problems must be solved. Circumvent a problem is > easy, resolve it is more hard. > > Currently 6bone and RIR have the same network topology (a lot of tunnels > and very little native links) and there is not transit provider, the > only difference beetween 6bone and RIR are address type (pTLA/sTLA) in > routing table. RIR space networks, at least in Germany and .NL, are strongly going to for native IPv6 peering at various peering points (AMS-IX, DECIX, INXS). [..] > You will guaranty routing over tunnel ? > Tunnels offer bad and random performance. > You can own your fiber, control your IPv4 network, but you will have > always the tunnel encapsulation. > > For provide a real production quality, you must have a native IPv6 > network without tunnels. If the tunnel is inside your own IPv4 network, you can control the performance nearly as well as on "native" links. Tunnels are a much larger problem if they cross unrelated 3rd-party networks. > Cut 6bone and RIR will be beneficial only if RIR have a lot of native > links and very little tunnels. We are working on it. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 49875 (48540) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Robert.Kiessling@de.easynet.net Thu Nov 21 18:14:22 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 21 Nov 2002 18:14:22 +0000 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021121164715.GJ25628@pasky.ji.cz> References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> <20021121164715.GJ25628@pasky.ji.cz> Message-ID: Petr Baudis writes: > Basically, Jan's proposal is like: the distribution of the prefixes does not > need to change fundamentally, the only change required is in 6bone -> RIRs > connections. In such passages, 6bone sites MUST NOT announce prefix 2001::/16 > nor any more specific prefixes matching this prefix, and RIR sites MUST filter > any such prefixes. That's an interesting proposal. However, I see one major disadvantage: The protection breaks down if only one of the connections between RIR and 6bone is not filtered. The "6bone sites don't exchange 2001::/16" model looks more robust in this respect. How would dual sites be handled? Would they count as "RIR" in this respect, i.e. they must filter RIR space from peerings with other 6bone (or dual) sites? One question which came to my mind: can this filtering be verified, e.g. by looking glasses? I think yes. Take BGP views from RIR sites and have a look at the AS paths for all 2001::/16 prefixes. If filtering is set up correctly, such AS paths may not contain any AS which is known to the 6bone whois, with the possible exception of first and last ASN for dual-RIR-and-6bone sites. Right? > it would be > probably nice not to prolong such flames and thus not to reply to such emails.) I very much second this. Robert From nicolas.deffayet@ndsoftware.net Thu Nov 21 18:29:55 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 21 Nov 2002 19:29:55 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021121164715.GJ25628@pasky.ji.cz> References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> <20021121164715.GJ25628@pasky.ji.cz> Message-ID: <1037903395.29705.74.camel@wks1.fr.corp.ndsoftware.com> On Thu, 2002-11-21 at 17:47, Petr Baudis wrote: Hi, > Basically, Jan's proposal is like: the distribution of the prefixes does not > need to change fundamentally, the only change required is in 6bone -> RIRs > connections. In such passages, 6bone sites MUST NOT announce prefix 2001::/16 > nor any more specific prefixes matching this prefix, and RIR sites MUST filter > any such prefixes. I agree, very good proposal. > + 6bone can do as much experimental stuff as they want to, they can still > NOT harm production traffic (production traffic should always ALWAYS go over > and use RIR space). Hum, i don't agree fully. 6bone must have a minimum of quality, 6bone should not be a dustbin. > + Whole 6bone still gets full RIR prefixes feed (with the original proposal, > each pTLA wouild need to have at least one full-transit peering with some sTLA > or direct peering with another pTLA which would have it; this would possibly > lead to further degenration of the 6bone hiearchy). I agree. > ? Roger says that they won't have their prefix "under control", but I fail to > see how it matters, if it won't harm their production RIR-RIR routing anymore. In all cases, they can't have their prefix "under control". When you announce a prefix, you can't control annonce of it by others AS. It's like in IPv4. > What are your proposals, opinions, thoughts, votes and so on? I support Jan's proposal. Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From gert@space.net Thu Nov 21 19:19:33 2002 From: gert@space.net (Gert Doering) Date: Thu, 21 Nov 2002 20:19:33 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <1037903395.29705.74.camel@wks1.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Thu, Nov 21, 2002 at 07:29:55PM +0100 References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> <20021121164715.GJ25628@pasky.ji.cz> <1037903395.29705.74.camel@wks1.fr.corp.ndsoftware.com> Message-ID: <20021121201933.J15927@Space.Net> Hi, On Thu, Nov 21, 2002 at 07:29:55PM +0100, Nicolas DEFFAYET wrote: > 6bone must have a minimum of quality, 6bone should not be a dustbin. Please try to understand that 6bone is not meant to stay forever. It's there to get IPv6 started, to collect experience, and to do experiments (that *will* harm stability). It is NOT a production network and it WILL go away in a few years. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 49875 (48540) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Jan Oravec Thu Nov 21 19:54:12 2002 From: Jan Oravec (Jan Oravec) Date: Thu, 21 Nov 2002 20:54:12 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021121192925.GL25628@pasky.ji.cz> References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> <20021121164715.GJ25628@pasky.ji.cz> <20021121192925.GL25628@pasky.ji.cz> Message-ID: <20021121195412.GA19349@hades.xs26.net> > > How would dual sites be handled? Would they count as "RIR" in this > > respect, i.e. they must filter RIR space from peerings with other > > 6bone (or dual) sites? > > I think that it depends on their own internal decision - they MUST at least > filter the prefixes properly at peerings with other RIRs, they probably SHOULD > filter them on the peerings with 6bone sites as they'd protect themselves. 6bone prefixes has nothing to do with it. There are just sites which have RIR space and the other sites which do not have. This model works perfectly even if site with RIR space advertises their 6bone prefix. So dual sites should be treated as RIR site. Regards, -- Jan Oravec XS26 coordinator 6COM s.r.o. 'Access to IPv6' http://www.6com.sk http://www.xs26.net From michael.a.cardosa@accenture.com Thu Nov 21 20:57:04 2002 From: michael.a.cardosa@accenture.com (michael.a.cardosa@accenture.com) Date: Thu, 21 Nov 2002 15:57:04 -0500 Subject: [6bone] IPv6 behind NAT Message-ID: I am new to IPv6, so please bare with me. I have a small home network that I would like to use to experiment with IPv6. I have a cable modem that is connected to my linux firewall/router. I would like to setup an IPv6 network within my existing network in the following manner: [sorry for the bad ascii art] cable modem | | linux router--------existing internal network(IP4) | | IPv6 router | | IPv6 internal network >From the documentation that I have read, I believe that I I need to have the IPv6 router do 6to4 translation (if that is the correct term). I am planning on using Red Hat for this. The other machines on the IPv6 will be Linux/BSD variants. I do not know, however, how to configure my router since it will have an internal NAT address and not the external one. Can somebody point me in the right direction? Thanks for any help mike This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. From tlangdon@atctraining.com.au Thu Nov 21 22:24:56 2002 From: tlangdon@atctraining.com.au (Tony Langdon) Date: Fri, 22 Nov 2002 09:24:56 +1100 Subject: [6bone] IPv6 behind NAT Message-ID: > I am new to IPv6, so please bare with me. I have a small > home network that > I would like to use > to experiment with IPv6. I have a cable modem that is connected to my > linux firewall/router. I > would like to setup an IPv6 network within my existing network in the > following manner: You need to make the NAT router the IPv6 router also. In this setup, the router will NAT for IPv4 and route (no NAT) for IPv6. This works for me. I have a /48 from freenet6 which is routed via the Linux NAT router. IPv6 hosts can see the IPv6 Internet no problems, while IPv4 is NAT'd as usual. Freenet6 suits my needs, because I can get static IPv6 addresses, even if my IPv4 changes, which it occasionally does. Running IPv6 behind IPv4 Nat via a tunnel (6to4 or whatever) is generally not supported (though I think some of the BSD variants have around this problem). --- Outgoing mail has been scanned for Viruses Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.419 / Virus Database: 235 - Release Date: 13/11/2002 This correspondence is for the named person’s use only. It may contain confidential or legally privileged information or both. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient. Any opinions expressed in this message are those of the individual sender. From gnea@garson.org Thu Nov 21 22:32:40 2002 From: gnea@garson.org (Scott Prader) Date: Thu, 21 Nov 2002 17:32:40 -0500 Subject: [6bone] IPv6 behind NAT In-Reply-To: References: Message-ID: <20021121223239.GP952@gnea.net> Generally, the best solution for your case is to obtain a Freenet6 IPv6 tunnel, which is available for free. Here's a brief technical breakdown on the setup: the linux box that's connected to the cable modem would act as the IPv6 router (using radvd or zebra). When you obtain the tunnel, you are assigned a single ip address, but from there you can easily request a /48 (that's 1208925819614629174706176 ip's with 65535 subnets. again, monetary cost can be related to /dev/zero). Basically toss an ip from the /48 on your eth1 connected to your hub/switch for your LAN and setup each Linux/BSD machine to autoconfigure, this way you won't have to deal with NAT (since you really can't anyhow unless you use static routes and that can get rather hairy and is generally not worth the effort, even in your situation). Once each of the LAN machines is configured right, they will obtain their IPv6 ips from the linux router, much like dhcp works with IPv4. That's a base start, however I highly recommend reading the documentation at www.ipv6.org, www.freenet6.net and www.hs247.org. Good luck. * michael.a.cardosa@accenture.com (michael.a.cardosa@accenture.com) cobbled forth: > > I am new to IPv6, so please bare with me. I have a small home network that > I would like to use > to experiment with IPv6. I have a cable modem that is connected to my > linux firewall/router. I > would like to setup an IPv6 network within my existing network in the > following manner: > > [sorry for the bad ascii art] > > cable modem > | > | > linux > router--------existing internal network(IP4) > | > | > IPv6 router > | > | > IPv6 internal network > > >From the documentation that I have read, I believe that I I need to have > the IPv6 router do > 6to4 translation (if that is the correct term). I am planning on using Red > Hat for this. The other > machines on the IPv6 will be Linux/BSD variants. I do not know, however, > how to configure > my router since it will have an internal NAT address and not the external > one. Can somebody > point me in the right direction? BTW, if it's a Cisco, I believe their latest IOS's support IPv6 and there's plenty of documentation floating around for it. google.com could help if that's the case. However, your best bet is to use the linux machine as an IPv6 router, unless you want to rewire your network. There are possibly other ways to achieve all of this, so take this all with a grain of salt. > Thanks for any help > mike .oO Gnea [gnea at garson dot org] Oo. .oO url [http://gnea.net] Oo. "You can tune a filesystem, but you can't tune a fish." -Kirk McKusick From alex@bit.nl Thu Nov 21 23:21:11 2002 From: alex@bit.nl (Alex Bik) Date: Fri, 22 Nov 2002 00:21:11 +0100 (MET) Subject: [6bone] RFC 2772 input from RIR space holder In-Reply-To: <1037893798.26572.7790.camel@wks1.fr.corp.ndsoftware.com> Message-ID: On 21 Nov 2002, Nicolas DEFFAYET wrote: > You will guaranty routing over tunnel ? If the underlaying layers are under my control? Yes. I don't see why not. > Tunnels offer bad and random performance. Don't mix up *your* tunnels with tunnels in general. > You can own your fiber, control your IPv4 network, but you will have > always the tunnel encapsulation. So your maximum packet size wil be a bit smaller. Big deal. > For provide a real production quality, you must have a native IPv6 > network without tunnels. That's bullshit and you know it. Tunnels in general are not bad. It's the way people build tunnels across the globe over infrastructure that they do not control that makes them bad. -- __________________ Met vriendelijke groet, /\ ___/ Alex Bik /- \ _/ Business Internet Trends BV AB2298-RIPE /--- \/ __________________ From tjc@ecs.soton.ac.uk Fri Nov 22 00:40:33 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Fri, 22 Nov 2002 00:40:33 +0000 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> <20021121164715.GJ25628@pasky.ji.cz> Message-ID: <20021122004032.GA8564@login.ecs.soton.ac.uk> On Thu, Nov 21, 2002 at 06:14:22PM +0000, Robert Kiessling wrote: > > That's an interesting proposal. You're assuming the 2001: space is "clean", which with its recent requirement relaxation and explosion is allocations, is less likely to be true (as people copy 6bone practice to the "production" space). Tim From jeroen@unfix.org Fri Nov 22 01:50:21 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 22 Nov 2002 02:50:21 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021122004032.GA8564@login.ecs.soton.ac.uk> Message-ID: <002101c291c9$856bbe40$210d640a@unfix.org> Tim Chown wrote: > On Thu, Nov 21, 2002 at 06:14:22PM +0000, Robert Kiessling wrote: > > > > That's an interesting proposal. > > You're assuming the 2001: space is "clean", which with its > recent requirement > relaxation and explosion is allocations, is less likely to be > true (as > people copy 6bone practice to the "production" space). Fortunally RIR space is company controlled, read: money. If a certain company is not playing the game along nicely that company will certainly get some 'nice attention' from all the other companies, probably the easiest way out is a depeer and/or the coming years in the hall of shame. A company needs to earn money and they are in it for the money not by fooling around. If their network is b0rked they won't get any customers or those customers will go to other networks. No cash, No company. Those problesm remedy theirselves. Greets, Jeroen From tjc@ecs.soton.ac.uk Fri Nov 22 02:54:12 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Fri, 22 Nov 2002 02:54:12 +0000 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <002101c291c9$856bbe40$210d640a@unfix.org> References: <20021122004032.GA8564@login.ecs.soton.ac.uk> <002101c291c9$856bbe40$210d640a@unfix.org> Message-ID: <20021122025412.GC8564@login.ecs.soton.ac.uk> On Fri, Nov 22, 2002 at 02:50:21AM +0100, Jeroen Massar wrote: > > Fortunally RIR space is company controlled, read: money. > If a certain company is not playing the game along nicely > that company will certainly get some 'nice attention' from > all the other companies, probably the easiest way out is a > depeer and/or the coming years in the hall of shame. > A company needs to earn money and they are in it for the > money not by fooling around. If their network is b0rked they > won't get any customers or those customers will go to other > networks. No cash, No company. Those problesm remedy theirselves. When they start to sell real commercial connectivity, I agree. I don't think we're at that point yet (catch22: because of 6bone-mess :) Similarly, I think many people in 3ffe space are very responsible. Tim From jeroen@unfix.org Fri Nov 22 11:55:12 2002 From: jeroen@unfix.org (Jeroen Massar) Date: Fri, 22 Nov 2002 12:55:12 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021122025412.GC8564@login.ecs.soton.ac.uk> Message-ID: <001001c2921e$0465cd90$210d640a@unfix.org> Tim Chown wrote: > On Fri, Nov 22, 2002 at 02:50:21AM +0100, Jeroen Massar wrote: > > > > Fortunally RIR space is company controlled, read: money. > > If a certain company is not playing the game along nicely > > that company will certainly get some 'nice attention' from > > all the other companies, probably the easiest way out is a > > depeer and/or the coming years in the hall of shame. > > A company needs to earn money and they are in it for the > > money not by fooling around. If their network is b0rked they > > won't get any customers or those customers will go to other > > networks. No cash, No company. Those problesm remedy theirselves. > > When they start to sell real commercial connectivity, I > agree. I don't > think we're at that point yet (catch22: because of 6bone-mess :) > > Similarly, I think many people in 3ffe space are very responsible. Apparently you don't know that you can BUY IPv6 transit and connectivity in many different parts of the world (Actually I think almost everywhere). You might contact: - VERIO - NTT / IIJ - GlobalCrossing and many others, as for endpoints, in Japan you can get a native IPv6 only line if you want it. That they don't sell it to your house yet doesn't mean it doesn't exist. In the Netherlands one can currently get Xs4all's PowerDSL which gives you native IPv6 and IPv4 on ADSL. Chello has native IPv6 for most parts of europe as far as I understood. So YES there is REAL commercial activity. And these people want it to work as they got clients paying for it. Just like IPv4. You might also note that the 6bone should have nothing to do with RIR space. And currently it has due to the 6bone mess. Greets, Jeroen From rjorgensen@upctechnology.com Fri Nov 22 10:41:49 2002 From: rjorgensen@upctechnology.com (Roger Jorgensen) Date: Fri, 22 Nov 2002 11:41:49 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021122025412.GC8564@login.ecs.soton.ac.uk> References: <002101c291c9$856bbe40$210d640a@unfix.org> <20021122004032.GA8564@login.ecs.soton.ac.uk> <002101c291c9$856bbe40$210d640a@unfix.org> Message-ID: <5.1.0.14.0.20021122114135.02bf0820@213.46.233.213> At 02:54 AM 11/22/2002 +0000, Tim Chown wrote: >On Fri, Nov 22, 2002 at 02:50:21AM +0100, Jeroen Massar wrote: > > > > Fortunally RIR space is company controlled, read: money. > > If a certain company is not playing the game along nicely > > that company will certainly get some 'nice attention' from > > all the other companies, probably the easiest way out is a > > depeer and/or the coming years in the hall of shame. > > A company needs to earn money and they are in it for the > > money not by fooling around. If their network is b0rked they > > won't get any customers or those customers will go to other > > networks. No cash, No company. Those problesm remedy theirselves. > >When they start to sell real commercial connectivity, I agree. I don't >think we're at that point yet (catch22: because of 6bone-mess :) Not sure it is a catch22 anymore. Are a group of sTLA people in Europe that have seen the point and also found out that unless they do something with the routing to get much closer to production quality there are no way to make money on IPv6 (key word: money) >Similarly, I think many people in 3ffe space are very responsible. Not all of 6bone are bad, those few that have a network and just let it keep running without looking much after it...not to forget some people that many sTLA holders don't trust at all. --- Roger Jorgensen (rjorgensen@upctechnology.com) System Engineer @ UPC Technology / IP engineering handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID From rjorgensen@upctechnology.com Fri Nov 22 13:50:55 2002 From: rjorgensen@upctechnology.com (Roger Jorgensen) Date: Fri, 22 Nov 2002 14:50:55 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <001001c2921e$0465cd90$210d640a@unfix.org> References: <20021122025412.GC8564@login.ecs.soton.ac.uk> Message-ID: <5.1.0.14.0.20021122144757.02bef800@213.46.233.213> At 12:55 PM 11/22/2002 +0100, Jeroen Massar wrote: >Chello has native IPv6 for most parts of europe as far as I understood. We have IPv6 in most of the countries where we are yes. Only place we are native IPv6 are Belgium. Are native from the customer to the core router.. --- Roger Jorgensen (rjorgensen@upctechnology.com) System Engineer @ UPC Technology / IP engineering handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID From pasky@xs26.net Fri Nov 22 14:17:47 2002 From: pasky@xs26.net (Petr Baudis) Date: Fri, 22 Nov 2002 15:17:47 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: Message-ID: <20021122141747.GS25628@pasky.ji.cz> Dear diary, on Thu, Nov 21, 2002 at 07:14:22PM CET, I got a letter, where Robert Kiessling told me, that... > Petr Baudis writes: > > > Basically, Jan's proposal is like: the distribution of the prefixes does not > > need to change fundamentally, the only change required is in 6bone -> RIRs > > connections. In such passages, 6bone sites MUST NOT announce prefix 2001::/16 > > nor any more specific prefixes matching this prefix, and RIR sites MUST filter > > any such prefixes. > > That's an interesting proposal. > > However, I see one major disadvantage: The protection breaks down if > only one of the connections between RIR and 6bone is not filtered. > > The "6bone sites don't exchange 2001::/16" model looks more robust in > this respect. Well, the protection breaks down if the 6bone sites will break that rule (which is *much* more likely, BTW). The protection is two-level here, 6bone site should filter outgoing and RIR site should filter incoming. And the breakage caused by one such a leak would be only minimal here, I believe; and as the time will go on and the density of production v6 network will raise, the harm will decrease exponentially. After all, Roger seemed so enthusiastic and confident about coordinating the RIRs.. ;-) > How would dual sites be handled? Would they count as "RIR" in this > respect, i.e. they must filter RIR space from peerings with other > 6bone (or dual) sites? I think that it depends on their own internal decision - they MUST at least filter the prefixes properly at peerings with other RIRs, they probably SHOULD filter them on the peerings with 6bone sites as they'd protect themselves. -- Petr "Pasky" Baudis . weapon, n.: An index of the lack of development of a culture. . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From nicolas.deffayet@ndsoftware.net Fri Nov 22 14:36:28 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 22 Nov 2002 15:36:28 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <5.1.0.14.0.20021122144757.02bef800@213.46.233.213> References: <20021122025412.GC8564@login.ecs.soton.ac.uk> <5.1.0.14.0.20021122144757.02bef800@213.46.233.213> Message-ID: <1037975788.29704.1437.camel@wks1.fr.corp.ndsoftware.com> On Fri, 2002-11-22 at 14:50, Roger Jorgensen wrote: > At 12:55 PM 11/22/2002 +0100, Jeroen Massar wrote: > > >Chello has native IPv6 for most parts of europe as far as I understood. > > We have IPv6 in most of the countries where we are yes. Only place > we are native IPv6 are Belgium. Are native from the customer to > the core router.. Do you plan to have IPv6 in France ? Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From nicolas.deffayet@ndsoftware.net Fri Nov 22 14:56:18 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 22 Nov 2002 15:56:18 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <001001c2921e$0465cd90$210d640a@unfix.org> References: <001001c2921e$0465cd90$210d640a@unfix.org> Message-ID: <1037976978.29701.1479.camel@wks1.fr.corp.ndsoftware.com> On Fri, 2002-11-22 at 12:55, Jeroen Massar wrote: > Apparently you don't know that you can BUY IPv6 transit and connectivity > in many different parts of the world (Actually I think almost > everywhere). > > You might contact: > - VERIO > - NTT / IIJ > - GlobalCrossing > > and many others, as for endpoints, in Japan you can get a native IPv6 > only line if you want it. That they don't sell it to your house yet > doesn't mean it doesn't exist. In the Netherlands one can currently > get Xs4all's PowerDSL which gives you native IPv6 and IPv4 on ADSL. It can be a good idea to do a full list of commercial IPv6 provider in the world like http://6bone.v6.wide.ad.jp/ipv6-service.html. -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From john@frumious.unidec.co.uk Fri Nov 22 16:22:55 2002 From: john@frumious.unidec.co.uk (dr john halewood) Date: Fri, 22 Nov 2002 16:22:55 +0000 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <001001c2921e$0465cd90$210d640a@unfix.org> References: <001001c2921e$0465cd90$210d640a@unfix.org> Message-ID: <200211221622.gAMGMuHD029876@frumious.unidec.co.uk> On Friday 22 November 2002 11:55 am, Jeroen Massar wrote: > Apparently you don't know that you can BUY IPv6 transit and connectivity > in many different parts of the world (Actually I think almost > everywhere). > > You might contact: > - VERIO > - NTT / IIJ > - GlobalCrossing That's interesting news to me. We're a customer of GlobalCrossing and are trying to get back onto the 6bone (we have an allocation from a while ago -see http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/USL-UK.html - but it appears that the 5F1A block has been discontinued and our upstream provider has disappeard). We contacted GlobalCrossing about getting an IPV6 feed and they looked completely blank about it. Maybe we were speaking to the wrong people there... cheers john From bmanning@ISI.EDU Fri Nov 22 16:39:34 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Fri, 22 Nov 2002 08:39:34 -0800 (PST) Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <200211221622.gAMGMuHD029876@frumious.unidec.co.uk> from dr john halewood at "Nov 22, 2 04:22:55 pm" Message-ID: <200211221639.gAMGdYd09768@boreas.isi.edu> % On Friday 22 November 2002 11:55 am, Jeroen Massar wrote: % > Apparently you don't know that you can BUY IPv6 transit and connectivity % > in many different parts of the world (Actually I think almost % > everywhere). % > % > You might contact: % > - VERIO % > - NTT / IIJ % > - GlobalCrossing % % That's interesting news to me. We're a customer of GlobalCrossing and are % trying to get back onto the 6bone (we have an allocation from a while ago % -see http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/USL-UK.html - but it % appears that the 5F1A block has been discontinued and our upstream provider % has disappeard). % % We contacted GlobalCrossing about getting an IPV6 feed and they looked % completely blank about it. Maybe we were speaking to the wrong people there... % % cheers % john depends on where you are, apparently. none of the above carriers is willing/able to give me native IPv6 in my market. its all going to be back-hauled via tunnels to places where they support native connections. :( tunnels are apparently still a useful tool. :) --bill From nicolas.deffayet@ndsoftware.net Fri Nov 22 17:08:53 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 22 Nov 2002 18:08:53 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <200211221622.gAMGMuHD029876@frumious.unidec.co.uk> References: <001001c2921e$0465cd90$210d640a@unfix.org> <200211221622.gAMGMuHD029876@frumious.unidec.co.uk> Message-ID: <1037984933.29695.1621.camel@wks1.fr.corp.ndsoftware.com> On Fri, 2002-11-22 at 17:22, dr john halewood wrote: > > - GlobalCrossing > > That's interesting news to me. We're a customer of GlobalCrossing and are > trying to get back onto the 6bone (we have an allocation from a while ago > -see http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/USL-UK.html - but it > appears that the 5F1A block has been discontinued and our upstream provider > has disappeard). > > We contacted GlobalCrossing about getting an IPV6 feed and they looked > completely blank about it. Maybe we were speaking to the wrong people there... Try to contact TT5-6BONE: http://whois.6bone.net/cgi-bin/whois?GLOBALCROSSING Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From JORDI PALET MARTINEZ" <200211221622.gAMGMuHD029876@frumious.unidec.co.uk> Message-ID: <035d01c28b42$efd548b0$e7472acc@consulintel.es> I've copied to the right people ;-) in Global Crossing, and I hope they will be able to reply you directly. Regards, Jordi ----- Original Message ----- From: "dr john halewood" To: <6bone@ISI.EDU> Sent: Friday, November 22, 2002 5:22 PM Subject: Re: [6bone] Re: RFC 2772 input from RIR space holder > On Friday 22 November 2002 11:55 am, Jeroen Massar wrote: > > Apparently you don't know that you can BUY IPv6 transit and connectivity > > in many different parts of the world (Actually I think almost > > everywhere). > > > > You might contact: > > - VERIO > > - NTT / IIJ > > - GlobalCrossing > > That's interesting news to me. We're a customer of GlobalCrossing and are > trying to get back onto the 6bone (we have an allocation from a while ago > -see http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/USL-UK.html - but it > appears that the 5F1A block has been discontinued and our upstream provider > has disappeard). > > We contacted GlobalCrossing about getting an IPV6 feed and they looked > completely blank about it. Maybe we were speaking to the wrong people there... > > cheers > john > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From gert@space.net Fri Nov 22 21:03:22 2002 From: gert@space.net (Gert Doering) Date: Fri, 22 Nov 2002 22:03:22 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021122004032.GA8564@login.ecs.soton.ac.uk>; from tjc@ecs.soton.ac.uk on Fri, Nov 22, 2002 at 12:40:33AM +0000 References: <7CEA40C0E10C7D4FBE076AE7C3EFB78D0114C53E@nlcbbms03> <20021121164715.GJ25628@pasky.ji.cz> <20021122004032.GA8564@login.ecs.soton.ac.uk> Message-ID: <20021122220322.W15927@Space.Net> Hi, On Fri, Nov 22, 2002 at 12:40:33AM +0000, Tim Chown wrote: > On Thu, Nov 21, 2002 at 06:14:22PM +0000, Robert Kiessling wrote: > > That's an interesting proposal. > > You're assuming the 2001: space is "clean", which with its recent requirement > relaxation and explosion is allocations, is less likely to be true (as > people copy 6bone practice to the "production" space). While Robert is assuming this, it does not really matter. If the 2001:: people mess up their stuff, peer pressure among ISPs has a good chance of cleaning that up (by dropping peerings and so on), but it's an "internal" thing - if 6bone messes up 2001:: routing, the established mechanisms for communication among ISPs just doesn't work anymore. So what Robert's proposal actually does is "encapsulate routing instabilities inside RIR space / inside 6bone space (wherever it originates)". If 6bone is unstable, RIR space can still be "productive", and are not directly affected. If RIR space is unstable, the RIR space holders have to fix it (and depending on the way filters will be set up, this might not necesarily affect 6bone space). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 50279 (49875) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From basit@basit.cc Sat Nov 23 09:42:15 2002 From: basit@basit.cc (Abdul Basit) Date: Sat, 23 Nov 2002 03:42:15 -0600 (CST) Subject: [6bone] LIN6/network based mobility Message-ID: <20021123033735.M90684-100000@wireless.cs.twsu.edu> Hello, does lin6 (LINA architecture) supports mobile routers (network based mobility instead of host-based mobility) ? If it does, where i can find some text on it ? i was unable to find some text on it at www.lin6.net, everything LIN6 considers is as node , and the node is host. Also, is there any discussion available on network-based mobility for Mobile IPv4 or Mobile IPv6? by network-based mobility means if your AR(access router) changes it point of attachment and moves into different network ? (MOnets for e.g deployed in space ships, airplanes, trains) etc? Waiting for any help in this regard. - basit Graduate Student Dept. of Computer Science Wichita state university From nicolas.deffayet@ndsoftware.net Sat Nov 23 13:02:50 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 23 Nov 2002 14:02:50 +0100 Subject: [6bone] BGP Ghost Routes (problem can be probably solved) Message-ID: <1038056569.20412.224.camel@wks1.fr.corp.ndsoftware.com> Hello, I have study the ghost routes of 4 pTLA (3ffe:200::/24, 3ffe:1400::/24, 3ffe:1e00::/24 and 3ffe:2400::/24) on 21 november. I have do: show ipv6 bgp 3ffe:200::/24 show ipv6 bgp 3ffe:1400::/24 show ipv6 bgp 3ffe:1e00::/24 show ipv6 bgp 3ffe:2400::/24 on the lookink-glass of this AS: AS680 (6WIN) AS1200 (AMS-IX) AS1853 (VIX) AS2513 (IMnet) AS3243 (Telepac) AS3246 (Song Networks) AS5609 (CSELT/TILAB) AS7521 (Internet Multifeed) AS12533 (RMnet) AS13193 (Nerim) AS13944 (EnterZone) AS15589 (Edisontel) AS24895 (Fubar) AS25356 (XS26) AS25358 (NDSoftware) Go to http://noc.ndsoftwarenet.com/bgp-ghost.html for have the result. Now, you can see that all ghost routes have a common ASN: AS10318 (in red bold). AS10318 is FIBERTEL (http://whois.6bone.net/cgi-bin/whois?FIBERTEL) If you have a peering with FIBERTEL, please send me a show ipv6 bgp. Any comments about this are welcome. Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From pekkas@netcore.fi Sat Nov 23 15:25:15 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Sat, 23 Nov 2002 17:25:15 +0200 (EET) Subject: [6bone] LIN6/network based mobility In-Reply-To: <20021123033735.M90684-100000@wireless.cs.twsu.edu> Message-ID: On Sat, 23 Nov 2002, Abdul Basit wrote: > does lin6 (LINA architecture) supports mobile routers (network > based mobility instead of host-based mobility) ? No. > Also, is there any discussion available on network-based mobility > for Mobile IPv4 or Mobile IPv6? Check 'nemo' working group under www.ietf.org. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From tjc@ecs.soton.ac.uk Mon Nov 25 16:52:45 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Mon, 25 Nov 2002 16:52:45 +0000 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <001001c2921e$0465cd90$210d640a@unfix.org> References: <20021122025412.GC8564@login.ecs.soton.ac.uk> <001001c2921e$0465cd90$210d640a@unfix.org> Message-ID: <20021125165245.GE19862@starling.ecs.soton.ac.uk> On Fri, Nov 22, 2002 at 12:55:12PM +0100, Jeroen Massar wrote: > > Apparently you don't know that you can BUY IPv6 transit and connectivity > in many different parts of the world (Actually I think almost > everywhere). > > You might contact: > - VERIO > - NTT / IIJ > - GlobalCrossing > > and many others, as for endpoints, in Japan you can get a native IPv6 > only line if you want it. That they don't sell it to your house yet > doesn't mean it doesn't exist. In the Netherlands one can currently > get Xs4all's PowerDSL which gives you native IPv6 and IPv4 on ADSL. > Chello has native IPv6 for most parts of europe as far as I understood. All this is very nice, but it doesn't mean stable, production quality IPv6 networking on an international basis. Buying it is one thing, being able to use it is another. Finding paths that perform as well for IPv6 as for IPv4 is very rare. I suggest you try some globetrotting to find the reality :( > So YES there is REAL commercial activity. And these people want it > to work as they got clients paying for it. Just like IPv4. But are those clients paying to trial IPv6, or paying to make money with IPv6 now? I severely doubt it's the latter (but would be very happy to be proved wrong :) > You might also note that the 6bone should have nothing to do with RIR > space. > And currently it has due to the 6bone mess. My suggestion is that while 3ffe: prefix sites are perhaps the greatest culprits, the 2001: space has its share too. Thus the way to get some kind of structure and predictability (and thus reliability) is for mutually interested networks to get together to talk policy - this is happening now for the major academic/research networks, some of whom are still in 6bone space (note that technically under the RIR rules, an NREN cannot get 2001: allocations as most do not serve 200 universities). Tim From Robert.Kiessling@de.easynet.net Mon Nov 25 18:04:40 2002 From: Robert.Kiessling@de.easynet.net (Robert Kiessling) Date: 25 Nov 2002 18:04:40 +0000 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021125165245.GE19862@starling.ecs.soton.ac.uk> References: <20021122025412.GC8564@login.ecs.soton.ac.uk> <001001c2921e$0465cd90$210d640a@unfix.org> <20021125165245.GE19862@starling.ecs.soton.ac.uk> Message-ID: Tim Chown writes: > My suggestion is that while 3ffe: prefix sites are perhaps the greatest > culprits, the 2001: space has its share too. That's certainly true. however there is a clear tendency: the most experimental and old stuff can be found in 6bone, and the most mature and native networks have 2001 space. > Thus the way to get some > kind of structure and predictability (and thus reliability) is for > mutually interested networks to get together to talk policy Well, you know that this is happening between LIRs. It's outside the scope of 6bone, though. Independant of other problems, 6bone should see to minimise its share of negative impact. > (note that technically under the RIR rules, an NREN > cannot get 2001: allocations as most do not serve 200 universities). This is just not true. "University" is not the only possibly entity to which you may assign addresses. Robert From tjc@ecs.soton.ac.uk Mon Nov 25 19:04:39 2002 From: tjc@ecs.soton.ac.uk (Tim Chown) Date: Mon, 25 Nov 2002 19:04:39 +0000 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: References: <20021122025412.GC8564@login.ecs.soton.ac.uk> <001001c2921e$0465cd90$210d640a@unfix.org> <20021125165245.GE19862@starling.ecs.soton.ac.uk> Message-ID: <20021125190439.GB28906@login.ecs.soton.ac.uk> On Mon, Nov 25, 2002 at 06:04:40PM +0000, Robert Kiessling wrote: > > > (note that technically under the RIR rules, an NREN > > cannot get 2001: allocations as most do not serve 200 universities). > > This is just not true. "University" is not the only possibly entity to > which you may assign addresses. Again I'm just reporting experience. I know of NRENs who have not applied for 2001: allocations because they do not have 200 customers (universities). They should not have to be "creative" to apply; there is no reason why an NREN with 60 univesities should not receive a SubTLA. Tim From gert@space.net Mon Nov 25 21:26:57 2002 From: gert@space.net (Gert Doering) Date: Mon, 25 Nov 2002 22:26:57 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021125190439.GB28906@login.ecs.soton.ac.uk>; from tjc@ecs.soton.ac.uk on Mon, Nov 25, 2002 at 07:04:39PM +0000 References: <20021122025412.GC8564@login.ecs.soton.ac.uk> <001001c2921e$0465cd90$210d640a@unfix.org> <20021125165245.GE19862@starling.ecs.soton.ac.uk> <20021125190439.GB28906@login.ecs.soton.ac.uk> Message-ID: <20021125222657.N15927@Space.Net> Hi, On Mon, Nov 25, 2002 at 07:04:39PM +0000, Tim Chown wrote: > Again I'm just reporting experience. I know of NRENs who have not applied > for 2001: allocations because they do not have 200 customers (universities). > They should not have to be "creative" to apply; there is no reason why > an NREN with 60 univesities should not receive a SubTLA. Seconded, and the discussion on the ipv6-wg/lir-wg mailing lists about this topic *is* open again. I'm mainly waiting for some decent proposal that includes NRENs and major transit-only networks (like NORDunet) but is on the other hand precise enough to not permit "any single enterprise that claims to be 'very important'" to get an sTLA. I wouldn't really mind if every LIR gets one (1) sTLA, but the last round of discussion has shown that neither the ARIN nor the APNIC people are willing to accept this very relaxed policy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 50279 (49875) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From mrp@mrp.net Tue Nov 26 02:24:01 2002 From: mrp@mrp.net (Mark Prior) Date: Tue, 26 Nov 2002 12:54:01 +1030 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021125190439.GB28906@login.ecs.soton.ac.uk> References: <20021122025412.GC8564@login.ecs.soton.ac.uk> <001001c2921e$0465cd90$210d640a@unfix.org> <20021125165245.GE19862@starling.ecs.soton.ac.uk> <20021125190439.GB28906@login.ecs.soton.ac.uk> Message-ID: At 7:04 PM +0000 25/11/02, Tim Chown wrote: >Again I'm just reporting experience. I know of NRENs who have not applied >for 2001: allocations because they do not have 200 customers (universities). >They should not have to be "creative" to apply; there is no reason why >an NREN with 60 univesities should not receive a SubTLA. > I think that if the NRENs actually asked their local RIR then they would discover that the RIR's are flexible in their determination. Mark. From pim@ipng.nl Tue Nov 26 08:16:26 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 26 Nov 2002 09:16:26 +0100 Subject: [6bone] Re: RFC 2772 input from RIR space holder In-Reply-To: <20021125222657.N15927@Space.Net> References: <20021122025412.GC8564@login.ecs.soton.ac.uk> <001001c2921e$0465cd90$210d640a@unfix.org> <20021125165245.GE19862@starling.ecs.soton.ac.uk> <20021125190439.GB28906@login.ecs.soton.ac.uk> <20021125222657.N15927@Space.Net> Message-ID: <20021126081626.GB16742@bfib.colo.bit.nl> On Mon, Nov 25, 2002 at 10:26:57PM +0100, Gert Doering wrote: | Hi, | | On Mon, Nov 25, 2002 at 07:04:39PM +0000, Tim Chown wrote: | > Again I'm just reporting experience. I know of NRENs who have not applied | > for 2001: allocations because they do not have 200 customers (universities). | > They should not have to be "creative" to apply; there is no reason why | > an NREN with 60 univesities should not receive a SubTLA. Tim, There has to be some demonstrated need for an allocation that is large enough to sustain several assignments to downstreams. If entities that are too small (which is extremely hard to define) were to be able to request subTLAs, we might start over-allocating, eg one /32 per 100 end-sites will get us in trouble in 10 years. We should think this through very well. At least it's become somewhat easier since 01/07/2002 and I'm very happy to see that the policies have been adopted worldwide regardless of service region. Gert said: | I'm mainly waiting for some decent proposal that includes NRENs and | major transit-only networks (like NORDunet) but is on the other hand | precise enough to not permit "any single enterprise that claims to | be 'very important'" to get an sTLA. | | I wouldn't really mind if every LIR gets one (1) sTLA, but the last | round of discussion has shown that neither the ARIN nor the APNIC | people are willing to accept this very relaxed policy. This opens the way for enterprises to gain their solution to the multihoming problems easily in the RIPE region and for a small fee (membership of a 'small' type LIR at RIPE is not that expensive). I am still scared that enterprises are gathering pTLAs to solve their problem of having to have an upstream provider. There's (at least) two groups here: (1) the companies that do not find decent connectivity in their direct area and therefor wish to have their own pTLA. (2) the companies that do not wish to be dependant on another company for their connectivity (political, multihomed, but also vanity). If you grant every LIR an sTLA, you might end up with a bunch of companies that become a LIR for the sole purpose of gaining an AS number and IPv4/IPv6 address block to be multihomed in the PA sense. I think we should have at least some extra rules in place in order to get an AS number and an IPv6 address block. By the way: the same holds for pTLAs. There should be some demonstrated need (eg conducting tests or preproduction strategies). Perhaps both can be quantified somehow. Also, we could discuss an upper bound on pTLA allocation timeframe (said 24 months). groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From raffaele.dalbenzio@tilab.com Thu Nov 28 10:47:50 2002 From: raffaele.dalbenzio@tilab.com (Raffaele D'Albenzio) Date: Thu, 28 Nov 2002 11:47:50 +0100 Subject: [6bone] New version of ASPath-tree available on line. Message-ID: <6ECEC1E214F2E342814ABB1ED10E79558A82BE@EXC2K01B.cselt.it> A new version of ASPath-tree (4.0) is available on line. Features of the new version: -- Added support for other router platforms. -- This version supports not only Cisco platforms but also Zebra and Juniper platforms. -- Improved BGP4+ routing table analysis: --supports ASsets and prepended AS numbers (showed in details pages) --choice to display received announces only (not consider local advertisement) --possible to filter out all suppressed or suppressed & learned through iBGP route entries -- new summary figures in home page page: --route summary (number of best/total routes), --AS summary (reserved ASes/private ASes), --Number of active peers (in terms of received prefixes) --AS distance summary -- highlight of private/reserved ASs in use You can download it starting from http://carmen.ipv6.tilab.com/cgi-bin/download.pl?pkg=ASpath-tree or see an example starting from http://net-stats.ipv6.tilab.com/bgp Regards, Raffaele. From schild@uni-muenster.de Thu Nov 28 13:11:46 2002 From: schild@uni-muenster.de (Christian Schild) Date: Thu, 28 Nov 2002 14:11:46 +0100 Subject: [6bone] Aggregation to /16 in the DFZ is not possible Message-ID: <200211281411.46147.ipng@uni-muenster.de> Dear 6boners, lately there were some discussions on the 6bone list improving 6bone traffic with the help of aggregating 6bone- or RIR-prefixes to a /16 aggreagate (3ffe::/16 and/or 2001::/16). Please note that this should be avoided in any case, because if we do so, we would introduce a default route into the "DFZ". As you might guess, this will lead to severe routing problems. Regards, Christian -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster Project Team email: Zentrum fuer Informationsverarbeitung join@uni-muenster.de Roentgenstrasse 9-13 http://www.join.uni-muenster.de D-48149 Muenster / Germany email: schild@uni-muenster.de,phone: +49 251 83 31638, fax: +49 251 83 31653 From Ronald.vanderPol@rvdp.org Thu Nov 28 15:03:18 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Thu, 28 Nov 2002 16:03:18 +0100 Subject: [6bone] New version of ASPath-tree available on line. In-Reply-To: <6ECEC1E214F2E342814ABB1ED10E79558A82BE@EXC2K01B.cselt.it> References: <6ECEC1E214F2E342814ABB1ED10E79558A82BE@EXC2K01B.cselt.it> Message-ID: <20021128150318.GE16983@rvdp.org> On Thu, Nov 28, 2002 at 11:47:50 +0100, Raffaele D'Albenzio wrote: > A new version of ASPath-tree (4.0) is available on line. Great. It is a nice tool which is installed at several sites. But are people acting on the data? > or see an example starting from http://net-stats.ipv6.tilab.com/bgp Hope you don't mind if I describe some data from your report. This is not a personal attack. I just hope to identify problem sites. I think your routing table is similar to many other sites. SE-DCS-20021104 is very unstable many different AS paths SE-DIGITAL-20010321 has 96% unavailability AS patch is: CHELLO - LITNET - SICS - AS8213 TNET-20011115 has 96% unavailability AS path is: CHELLO - LITNET LT-DELFI-20020924 has 96% unavailability AS path is: CHELLO - LITNET - HLP IPV6 Ah, see the pattern. Do others see problems wit CHELLO or LITNET? Many have 100% unavailability: ZAMA-AP-20010320 SAMSUNGNETWORKS-KRNIC-KR-20010920 TOCN-20020513 NUS-SG-19990827 DISN-LES-V6 SPRINT-V6 UNAM-IPV6 QWEST-IPV6-1 WAYPORT-IPV6 EU-DANTE-20020131 SKTELECOMNET-KRNIC-KR-20010406 CERNET-CN-20000426 AOLTIMEWARNER KOLNET-KRNIC-KR-20000927 HANANET-KRNIC-KR-20001030 DE-ECRC-19991223 NGINET-KRNIC-KR-20010115 UK-INS-20010518 FBDC-JPNIC-JP-20020524 IT-GARR-20011004 DE-JIPPII-20000426 DREN-V6 ETRI-KRNIC-KR-19991124 IT-CSP-20020725 EP-NET INTEROP-JP-20020617 PL-CYFRONET-20010221 AT-INODE-20021112 CANET3-IPV6 KREONET2-KRNIC-KR-20010823 NET-CW-10BLK FI-SONERA-20011231 FR-TELECOM-20000623 CISCO-IPV6-1 That's a large part of the 6bone that is unreachable from your site. rvdp From Raffaele.Dalbenzio@TILAB.COM Thu Nov 28 15:44:37 2002 From: Raffaele.Dalbenzio@TILAB.COM (D'Albenzio Raffaele) Date: Thu, 28 Nov 2002 16:44:37 +0100 Subject: [6bone] New version of ASPath-tree available on line. Message-ID: <6ECEC1E214F2E342814ABB1ED10E7955AF5F74@EXC2K01B.cselt.it> Hello Ronald, no problem for your comments. About the 100% unavailability of RIR allocated prefixes sometimes the problem is because there are some LIRs that asked to extend their prefix from /35 to /32 but they continue announcing /35. >From ASPath-tree point of view in that case the real prefix it should see is a /32. and if the /32 is not present in the the routing table thant ASPath-tree considers the sTLA unavailable. Regards, Raffaele. > -----Original Message----- > From: Ronald van der Pol [mailto:Ronald.vanderPol@rvdp.org] > Sent: Thursday, November 28, 2002 4:03 PM > To: D'Albenzio Raffaele > Cc: 6bone@ISI.EDU > Subject: Re: [6bone] New version of ASPath-tree available on line. > > > On Thu, Nov 28, 2002 at 11:47:50 +0100, Raffaele D'Albenzio wrote: > > > A new version of ASPath-tree (4.0) is available on line. > > Great. It is a nice tool which is installed at several sites. > But are people acting on the data? > > > or see an example starting from http://net-stats.ipv6.tilab.com/bgp > > Hope you don't mind if I describe some data from your report. > This is not a personal attack. I just hope to identify > problem sites. I think your routing table is similar to many > other sites. > > SE-DCS-20021104 is very unstable > many different AS paths > > SE-DIGITAL-20010321 has 96% unavailability > AS patch is: CHELLO - LITNET - SICS - AS8213 > > TNET-20011115 has 96% unavailability > AS path is: CHELLO - LITNET > > LT-DELFI-20020924 has 96% unavailability > AS path is: CHELLO - LITNET - HLP IPV6 > > Ah, see the pattern. Do others see problems wit CHELLO or LITNET? > > Many have 100% unavailability: > ZAMA-AP-20010320 > SAMSUNGNETWORKS-KRNIC-KR-20010920 > TOCN-20020513 > NUS-SG-19990827 > DISN-LES-V6 > SPRINT-V6 > UNAM-IPV6 > QWEST-IPV6-1 > WAYPORT-IPV6 > EU-DANTE-20020131 > SKTELECOMNET-KRNIC-KR-20010406 > CERNET-CN-20000426 > AOLTIMEWARNER > KOLNET-KRNIC-KR-20000927 > HANANET-KRNIC-KR-20001030 > DE-ECRC-19991223 > NGINET-KRNIC-KR-20010115 > UK-INS-20010518 > FBDC-JPNIC-JP-20020524 > IT-GARR-20011004 > DE-JIPPII-20000426 > DREN-V6 > ETRI-KRNIC-KR-19991124 > IT-CSP-20020725 > EP-NET > INTEROP-JP-20020617 > PL-CYFRONET-20010221 > AT-INODE-20021112 > CANET3-IPV6 > KREONET2-KRNIC-KR-20010823 > NET-CW-10BLK > FI-SONERA-20011231 > FR-TELECOM-20000623 > CISCO-IPV6-1 > > That's a large part of the 6bone that is unreachable from your site. > > rvdp > ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you ==================================================================== From nicolas.deffayet@ndsoftware.net Fri Nov 29 00:24:11 2002 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 29 Nov 2002 01:24:11 +0100 Subject: [6bone] Re: 6bone pTLA 3FFE:4013::/32 allocated to NDSOFTWARE In-Reply-To: <5.1.0.14.0.20021110184240.03185b00@imap2.es.net> References: <5.1.0.14.0.20021110184240.03185b00@imap2.es.net> Message-ID: <1038529451.15155.2560.camel@wks1.fr.corp.ndsoftware.com> Hello, > [To create a reverse DNS registration for pTLAs, please send the prefix > allocated above, and a list of at least two authoritative nameservers, to > hostmaster@ep.net.] I have send an email on 11 Nov 2002 04:13:55 +0100 to hostmaster@ep.net for createa reverse DNS registration for 3ffe:4013::/32. I have resend my email 3 times but always no reply of hostmaster@ep.net How NDSoftware can get reverse for its pTLA if hostmaster@ep.net don't reply ? Best Regards, -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ From pim@ipng.nl Fri Nov 29 20:28:48 2002 From: pim@ipng.nl (Pim van Pelt) Date: Fri, 29 Nov 2002 21:28:48 +0100 Subject: [6bone] Aggregation to /16 in the DFZ is not possible In-Reply-To: <200211281411.46147.ipng@uni-muenster.de> References: <200211281411.46147.ipng@uni-muenster.de> Message-ID: <20021129202848.GB14556@bfib.colo.bit.nl> On Thu, Nov 28, 2002 at 02:11:46PM +0100, Christian Schild wrote: | Dear 6boners, | | lately there were some discussions on the 6bone list improving | 6bone traffic with the help of aggregating 6bone- or RIR-prefixes | to a /16 aggreagate (3ffe::/16 and/or 2001::/16). I was thinking more along the lines of two routers for IPv6. One would be connected to AMS-v6-IX natively (in my case) and does not accept any 3ffe::/16 stuff, the other would accept any prefixes from its peers but tag them with a lower localpref so routes over AMS-IX would be more prefered. I think this will solve near-local connectivity issues for my particular setup. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From synviv@yahoo.com Fri Nov 29 20:49:23 2002 From: synviv@yahoo.com (Vivek Shekhar) Date: Fri, 29 Nov 2002 12:49:23 -0800 (PST) Subject: [6bone] IPv6 Transition help Message-ID: <20021129204923.1322.qmail@web9302.mail.yahoo.com> Hello Group, I am a Masters' student in Computer Networking at a University in United States presently working on migration from IPv4 to IPv6. My project aims at not only describing these transition mechanisms but also providing scenarios/cases where one transition mechanism would be more beneficial than the other with reasons. Although there are hundreds of links available for the transition mechanisms there are few that aid in choosing a specfic mechanism over the other. Let me give you a more detailed perspective of what I really want. >From RFC 2893: The following transition mechanisms are described Dual IP layer (also known as Dual Stack): A technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers. Configured tunneling of IPv6 over IPv4: Point-to-point tunnels made by encapsulating IPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures. IPv4-compatible IPv6 addresses: An IPv6 address format that employs embedded IPv4 addresses. Automatic tunneling of IPv6 over IPv4: A mechanism for using IPv4-compatible addresses to automatically tunnel IPv6 packets over IPv4 networks. Now given the above 4 mechanisms, under what scenarios would u choose one over the other. What factors should I consider. I have come up with cost,time to process the packets, complexity etc. Since I do not have nay industry relevant experience I am banking on this mailing group to provide me with some helpful information. Looking forward to your response. Cheers. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com