Subject: RE: IPv6 in the network, please

From: [email-masked]
Date: Wed, 10 Nov 2004 18:43:07 -0000

So somebody needs to get Airespace's marketroids to slow down a little
bit:

http://www.airespace.com/news/press_releases/04_1026b.php

--Mat

P.S. Sincere thanks to the IETF61 NOC for making these efforts to get
IPv6 functional on the entire network - I'll try that new config now
from Lincoln.

On , [email-masked] (mailto:[email-masked]) wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Begin forwarded message:
> 
>> From: Ben Crosby <[email-masked]>
>> Date: November 10, 2004 12:07:08 PM EST
>> To: [email-masked]
>> Subject: IPv6
>> Reply-To: Ben Crosby <[email-masked]>
>> 
>> Folks,
>> 
>> 	To expand on Jeff's explanation of the IPv6 status here at
IETF61;
>> The entire network, both wired and wireless, was designed from the
>> get-go as being IPv6 capable. It also had a very real and major
>> requirement to be stable in the face of hundreds of clients all at
>> 100% transmit power, rogue APs,  and all the other problems that have
>> plagued previous IETF wireless networks. The good folks at Airespace
>> seemed to have a system that met this goal, and as we all can see,
>> it indeed works well. 
>> 
>> 	However, when we asked Airespace to join us in this adventure,
it
>> became clear that the "intelligence" of their system worked through
>> tracking IPv4 DHCP requests, and thus wouldn't work with IPv6. This
>> lack of IPv6 support was nearly a show stopper, however Airespace
>> jumped through some major hoops to design, implement, and deploy code
>> that monitors RAs and RSs specifically to handle IPv6 for this
>> network. 
>> 
>> 	Like most brand new code, when we deployed it, we encountered
>> problems. Problems that lead to instability in ALL wireless network
>> access. After several long days and nights of working on this long
>> before the first attendees arrived (we've been on site since Tuesday
>> 2nd - Election Day ;) we decided to disable the IPv6 support on the
>> wireless network, rather than risk the overall network stability.
>> Airespace continues to work on the problems, and we believe that we
>> have a reasonable interim solution.
>> 
>> 	We have phased in a new image with limited deployment, which we
will
>> monitor. If we experience no problems, IPv6 will be back on the
>> wireless lan, however we need to maintain the overall stability of
>> the wireless network as our highest priority.
>> 
>> 	For those who need IPv6 on wireless:
>> 
>> 	SSID: ietf61v6
>> 	WEP Key: thisisav6wlan
>> 	Hex: 746869736973617636776c616e
>> 
>> 	Coverage will be available in Georgetown, Lincoln, Jefferson,
>> Monroe, Military and Hemisphere. You should not associate with this
>> wireless network if you need stable IPv4. This is a dedicated
>> network with new AP's and a new controller. 
>> 
>> 	My thanks to our volunteer staff who worked to deploy this
network
>> in the late hours last night (and very early hours this morning)
>> after the social event. 
>> 
>> 	For those that are inconvenienced by the loss of IPv6, I
sincerely
>> apologize, and remind you that native IPv6 is available at every
>> wired port in the terminal room. 
>> 
>> 	Thanks for bearing with us, and have a good meeting!
>> 
>> 	- Ben Crosby
>> 	Alcatel / IETF61 NOC
>> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (Darwin)
> 
> iD8DBQFBklluLWqnmaznXfoRAi/qAJ4nUW48fV51MGYwRdX1IOqh2OAYHQCgvyZT
> nuUrX42hGaM8Xg7/fKPj1jc= =t7zw
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 10 Nov 2004 14:18:31 -0500

Agree, good job. Is working for me since over 10 minutes ago.

BUT the routing to Europe is really stupid and absolutely unacceptable:
Ordenador-de-Jordi-Palet:/Users/Jordi/Desktop jordi$ traceroute6
www.euro6ix.org   
traceroute6 to www.euro6ix.org (2001:800:40:2a03::3) from
2001:468:c12:136:20d:93ff:feeb:73, 30 hops max, 12 byte packets
 1  2001:468:c12:136::4  2.491 ms  1.672 ms  1.641 ms
 2  2001:468:c12:1::1  2.353 ms  2.463 ms  2.387 ms
 3  2001:468:ff:185c::1  17.22 ms *  3.112 ms
 4  atlang-washng.abilene.abilene.ucaid.edu  21.407 ms  18.55 ms  18.519 ms
 5  hstnng-atlang.abilene.ucaid.edu  44.552 ms  43.544 ms  38.279 ms
 6  losang-hstnng.abilene.ucaid.edu  69.868 ms  69.807 ms *
 7  3ffe:8140:101:1::2  178.257 ms  173.559 ms  174.291 ms
 8  hitachi1.otemachi.wide.ad.jp  175.771 ms  174.657 ms  173.76 ms
 9  pc6.otemachi.wide.ad.jp  195.116 ms  183.588 ms  190.05 ms
10  * 3ffe:1800::3:2d0:b7ff:fe9a:6233  185.624 ms  183.481 ms
11  3ffe:1800::3:230:48ff:fe41:4e95  184.689 ms  183.501 ms  184.908 ms
12  2001:468:ff:16c1::5  183.309 ms  184.138 ms  194.804 ms
13  v6-tunnel62-uk6x.ipv6.btexact.com  457.111 ms  456.848 ms  455.127 ms
14  2001:800:40:2e02::1  513.549 ms  511.013 ms  515.763 ms
15  2001:800:40:2f02::2  514.232 ms  512.886 ms  520.444 ms
16  ns1.euro6ix.com  520.54 ms  516.964 ms  510.757 ms

Can we please fix this, PLEASE ? No idea why hasn't been fixed already since
when reported on Monday, in parallel with the rest.

By the way, the press should take note about Airespace marketing versus
reality. I hope this company can be honest an make a public correction on
that, otherwise customers should not trust them anymore.

Regards,
Jordi

> De: [email-masked]
> Responder a: [email-masked]
> Fecha: Wed, 10 Nov 2004 18:43:07 -0000
> Para: <[email-masked]>, <[email-masked]>
> Asunto: RE: IPv6 in the network, please
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Nov 2004 20:39:36 +0100

> Agree, good job. Is working for me since over 10 minutes ago.

Not for me. But interestingly, I've never been able to get an IPv4
address (or any responses) to DHCP queries from dhcpcd-1.3.22_p4 on
Linux on the v4 network. However, I managed to get a response and an
IPv4 address on the IETF61IPv6 network.

Stig

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Nov 2004 14:43:40 -0500

> that, otherwise customers should not trust them anymore.

Oh, come on, give them some slack.
Companies announce products that in reality are in beta ("1.0") all the 
time.

I think it's great they are working on IPv6 support, and that they are 
getting good beta feedback from this site.

Gruesse, Carsten

---

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Nov 2004 20:51:36 +0100

> Agree, good job. Is working for me since over 10 minutes ago.

Now v6 works for me as well. I think perhaps my initial RS was ignored
for some reason, but I received a later RA. Not sure.

Anyway, I now have working v6 as well, and for me the routing is perfect:

traceroute to sverresborg.uninett.no (2001:700:e000:0:204:75ff:fee4:423b) from 2001:468:c12:136:205:4eff:fe40:1762, 30 hops max, 16 byte packets
 1  2001:468:c12:136::4 (2001:468:c12:136::4)  2.252 ms  2.897 ms  5.934 ms
 2  2001:468:c12:1::1 (2001:468:c12:1::1)  9.827 ms  2.893 ms  8.934 ms
 3  2001:468:ff:185c::1 (2001:468:ff:185c::1)  10.812 ms  3.932 ms  3.91 ms
 4  abilene.de2.de.geant.net (2001:798:2014:20aa::1)  96.823 ms  98.937 ms  109.962 ms
 5  de.se1.se.geant.net (2001:798:20cc:1402:2501::2)  116.966 ms  122.937 ms  117.96 ms
 6  nordunet-gw.se1.se.geant.net (2001:798:2025:10aa::2)  116.723 ms  114.947 ms  119.942 ms
 7  sw-gw.nordu.net (2001:948:0:f026::1)  115.955 ms  115.943 ms  115.961 ms
 8  6net-gw.nordu.net (2001:948:0:f02a::2)  115.972 ms  115.938 ms  115.953 ms
 9  6net-gw.uninett.no (2001:948:0:f03a::2)  122.955 ms  123.945 ms  168.977 ms
10  oslo-gw1.uninett.no (2001:700:0:10d::1)  134.935 ms  123.957 ms  122.944 ms
11  trd-gw.uninett.no (2001:700:0:10::2)  132.927 ms  130.938 ms  134.954 ms
12  teknobyen-gw.uninett.no (2001:700:0:50b::2)  130.958 ms  130.942 ms  135.958 ms
13  uninett-gw.uninett.no (2001:700:0:510::2)  133.97 ms  132.934 ms  135.956 ms
14  sverresborg.uninett.no (2001:700:e000:0:204:75ff:fee4:423b)  130.958 ms  144.943 ms  133.958 ms

That is, from here to a host in Norway.

I don't understand why I can't get IPv4 address with DHCP on v4 network
but on v6 network. But using v6 network I have working v6 AND v4 and am
quite happy.

Thanks for all the work you've put in,

Stig

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Nov 2004 19:54:39 +0000

I am in International E, without v6 on WLAN, but can v4 ssh home and
trace from there to the v6 router here.  Then I see VERY good response
over the JANET-GEANT-Abilene-IETF route.   

Maybe it's a Euro6IX issue for you, for specific routing to that prefix
as opposed to the production prefix, if GEANT does offer transit for you?

(You might try asking to [email-masked])

login ~]$ /usr/sbin/traceroute6 2001:468:c12:1::1
traceroute to 2001:468:c12:1::1 (2001:468:c12:1::1) from 2001:630:d0:115:230:48ff:fe23:58df, 30 hops max, 16 byte packets
 1  servers-router.6core.ecs.soton.ac.uk (2001:630:d0:115::1)  0.431 ms  0.276 ms  0.275 ms
 2  zaphod.6core.ecs.soton.ac.uk (2001:630:d0:101::1)  0.841 ms  0.527 ms  0.706 ms
 3  ford.6core.ecs.soton.ac.uk (2001:630:d0:100::1)  0.99 ms  0.975 ms  1.668 ms
 4  2001:630:c1:100::1 (2001:630:c1:100::1)  1.309 ms  1.411 ms  0.952 ms
 5  2001:630:c1:10::1 (2001:630:c1:10::1)  2.855 ms  1.851 ms  2.023 ms
 6  * * *
 7  2001:630:c1::1 (2001:630:c1::1)  3.35 ms  2.651 ms  2.379 ms
 8  2001:630:c1::1 (2001:630:c1::1)  2.338 ms  3.192 ms  2.778 ms
 9  po9-0.cosh-scr.ja.net (2001:630:0:10::85)  79.361 ms  3.606 ms  3.264 ms
10  po2-0.lond-scr.ja.net (2001:630:0:10::29)  5.147 ms  5.02 ms  7.123 ms
11  po6-0.lond-scr3.ja.net (2001:630:0:10::36)  5.306 ms  4.906 ms  5.095 ms
12  2001:630:0:10::166 (2001:630:0:10::166)  5.447 ms  4.241 ms  4.248 ms
13  janet.uk1.uk.geant.net (2001:798:2028:10aa::1)  5.798 ms  5.709 ms  5.006 ms
14  uk.ny1.ny.geant.net (2001:798:20cc:1c01:2801::1)  74.333 ms  74.8 ms  73.537 ms
15  nycmng-esnet.abilene.ucaid.edu (2001:468:ff:15c3::1)  78.41 ms  128.5 ms  74.054 ms
16  washng-nycmng.abilene.ucaid.edu (2001:468:ff:1518::2)  101.141 ms  95.373 ms  96.015 ms
17  max-washng.abilene.ucaid.edu (2001:468:ff:184c::2)  95.498 ms  94.944 ms  94.517 ms
18  2001:468:c12:1::1 (2001:468:c12:1::1)  95.006 ms  108.128 ms  96.164 ms

-- 
Tim

North American IPv6 Task Force Technologist Seminar
More info at http://www.ipv6seminar.com/

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Nov 2004 23:31:40 +0200 (EET)

This is probably already inappropriate to the IETF list, but to be 
fair to the admin folks...

> BUT the routing to Europe is really stupid and absolutely unacceptable:
[...]
> Can we please fix this, PLEASE ? No idea why hasn't been fixed 
> already since when reported on Monday, in parallel with the rest.

What is the exact thing you're complaining about?  The fact that you 
use an ISP which you use (or some of its upstreams) hasn't set up 
sufficient peering/transit? :)  It surely looks like a problem at UK6x 
or the first hop ISP..

Internet2 connectivity is reasonably good. To be fair, this is not the 
right place to blame for this inoptimal routing.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Brett Thorson" <[email-masked]>
Date: Wed, 10 Nov 2004 17:32:39 -0500 (EST)

Sorry to send this back to this list.  But if people are having problems,
I would encourage them (as well as yourself) to come to the NOC (at any
IETF, this one or any future IETF).  That way we can ask questions like
"What is your MAC address" and offer a solution as quick as possible.

In any case, the solution, as far as we can tell, is that your ability to
receive DHCP offers on your linux system is broken.

Here are the logs.  If you have more issues, I highly encourage you to
either take the problem to a "Trouble with DHCP on linux list" or come to
the NOC to continue the exploration.

Cheers!

Nov  8 15:27:52 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via
130.129.128.80
Nov  8 15:27:53 (none) dhcpd: DHCPOFFER on 130.129.134.174 to
00:05:4e:40:17:62 via 130.129.128.80
Nov  8 15:29:35 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 
130.129.128.80
Nov  8 15:29:36 (none) dhcpd: DHCPOFFER on 130.129.134.174 to
00:05:4e:40:17:62 via 130.129.128.80
Nov  8 15:29:43 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 
130.129.128.80
Nov  8 15:29:43 (none) dhcpd: DHCPOFFER on 130.129.134.174 to
00:05:4e:40:17:62 via 130.129.128.80
Nov  8 15:29:59 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 
130.129.128.80
Nov  8 15:29:59 (none) dhcpd: DHCPOFFER on 130.129.134.174 to
00:05:4e:40:17:62 via 130.129.128.80
Nov  8 15:30:59 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 
130.129.128.80
Nov  8 15:30:59 (none) dhcpd: DHCPOFFER on 130.129.134.174 to
00:05:4e:40:17:62 via 130.129.128.80
Nov  8 15:30:59 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 
130.129.128.80
Nov  8 15:30:59 (none) dhcpd: DHCPOFFER on 130.129.134.174 to
00:05:4e:40:17:62 via 130.129.128.80
Nov  8 15:32:32 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 
130.129.128.80

Nov  8 15:32:33 (none) dhcpd: DHCPREQUEST for 130.129.134.174
(130.129.16.20) from 00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80
Nov  8 15:32:33 (none) dhcpd: DHCPACK on 130.129.134.174 to
00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80
Nov  8 15:53:21 (none) dhcpd: DHCPRELEASE of 130.129.134.174 from 
00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80 (found)
Nov  8 15:53:32 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 
130.129.128.80
Nov  8 15:53:33 (none) dhcpd: DHCPOFFER on 130.129.134.174 to
00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80
Nov  8 15:53:33 (none) dhcpd: DHCPREQUEST for 130.129.134.174
(130.129.16.20) from 00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80
Nov  8 15:53:33 (none) dhcpd: DHCPACK on 130.129.134.174 to
00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80
Nov  8 16:17:19 (none) dhcpd: DHCPRELEASE of 130.129.134.174 from 
00:05:4e:40:17:62 (silkesvarten) via 130.12

--Brett

> Not for me. But interestingly, I've never been able to get an IPv4
address (or any responses) to DHCP queries from dhcpcd-1.3.22_p4 on Linux
on the v4 network. However, I managed to get a response and an IPv4
address on the IETF61IPv6 network.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 10 Nov 2004 19:45:24 -0500

Hi Brett,

May be is even easier to setup a [email-masked] ?

Just a suggestion, some of us get really crazy during this week to have
additional time for going "physically" into the NOC.

Regards,
Jordi

> De: "Brett Thorson" <[email-masked]>
> Responder a: [email-masked]
> Fecha: Wed, 10 Nov 2004 17:32:39 -0500 (EST)
> Para: "Stig Venaas" <[email-masked]>, [email-masked]
> CC: JORDI PALET MARTINEZ <[email-masked]>
> Asunto: Re: IPv6 in the network, please
>

---

From: Stig Venaas <[email-masked]>
Date: Thu, 11 Nov 2004 01:56:26 +0100

> receive DHCP offers on your linux system is broken.

Not sure if I should take this to the list either. But I think what
you see there is the requests made from windows. I switched to windows
because that worked.

> the NOC to continue the exploration.

It works for other Linux users I've talked to, but they may not be
using dhcpcd. I'm told dhcpcd has some bugs which I'm willing to
believe. I don't have the time to research this now. I might be
interested in hearing from others, in private, that are using dhcpcd
whether they have problems.

I may stop by the NOC, but it's no big deal. I should have done so
earlier in the week.

Stig