Re: IETF IPv6 platform configuration
My recent experiences with ftp.ietf.org: EPSV doesn't work - it gives a port which it then isn't listening on (or, more likely since we get no response at all, a firewall blocks connections to): ftp ls --- EPSV 229 Entering Extended Passive Mode (|||42065|) ftp: connect for data channel: Operation timed out [simultaneously in another window] compost% telnet ftp.ietf.org 42065 Trying 156.154.16.149... telnet: connect to address 156.154.16.149: Operation timed out EPRT for IPv4 doesn't work - it returns an error Bad EPRT protocol. --- EPRT |1|192.20.225.40|56318| 500 Bad EPRT protocol. Apparently, the FTP server doesn't want to allow EPRT with IPv4. (1 is IPv4). It's not using the 522 I don't support that protocol error code, but is also saying that it doesn't support that protocol. PORT doesn't work - it returns an immediate error Failed to establish connection. --- PORT 192,20,225,40,219,254 200 PORT command successful. Consider using PASV. --- LIST 425 Failed to establish connection. tcpdump shows that it didn't send any packets trying to establish a connection to 192.20.225.40 and the 425 error comes too quickly to have tried. It looks like 3 out of 4 data channel establishment mechanisms are broken with this FTP server software and configuration for IPv4. I didn't test with IPv6. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF IPv6 platform configuration
We are looking into this and will post a response as soon as we have some more information. As always, thanks for the notification!! Jon Lindberg NSS -Original Message- From: Bill Fenner [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 10:46 AM To: Ken Raeburn Cc: [EMAIL PROTECTED]; ietf Mailing List Subject: Re: IETF IPv6 platform configuration My recent experiences with ftp.ietf.org: EPSV doesn't work - it gives a port which it then isn't listening on (or, more likely since we get no response at all, a firewall blocks connections to): ftp ls --- EPSV 229 Entering Extended Passive Mode (|||42065|) ftp: connect for data channel: Operation timed out [simultaneously in another window] compost% telnet ftp.ietf.org 42065 Trying 156.154.16.149... telnet: connect to address 156.154.16.149: Operation timed out EPRT for IPv4 doesn't work - it returns an error Bad EPRT protocol. --- EPRT |1|192.20.225.40|56318| 500 Bad EPRT protocol. Apparently, the FTP server doesn't want to allow EPRT with IPv4. (1 is IPv4). It's not using the 522 I don't support that protocol error code, but is also saying that it doesn't support that protocol. PORT doesn't work - it returns an immediate error Failed to establish connection. --- PORT 192,20,225,40,219,254 200 PORT command successful. Consider using PASV. --- LIST 425 Failed to establish connection. tcpdump shows that it didn't send any packets trying to establish a connection to 192.20.225.40 and the 425 error comes too quickly to have tried. It looks like 3 out of 4 data channel establishment mechanisms are broken with this FTP server software and configuration for IPv4. I didn't test with IPv6. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
On Thursday, July 06, 2006 10:45:52 AM -0400 Bill Fenner [EMAIL PROTECTED] wrote: It looks like 3 out of 4 data channel establishment mechanisms are broken with this FTP server software and configuration for IPv4. I didn't test with IPv6. I did, inadvertently. PASV worked, as did at least one of PORT and EPSV. I didn't try EPRT. My guess is that there's some _thing_ in the IPv4 path that is breaking things because it doesn't like PORT and doesn't support the extended modes, either because it's too old or too broken. This is one of the reasons for both the layered network model and the end-to-end principle -- avoiding the need for devices in the middle of the network to understand application protocols not only makes it easier to deploy new applications, but also reduces the chances that some device you have no control over will break the applications you already have. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
Just for completeness, I configured 6to4 to get IPv6 working. Both EPSV and EPRT work with IPv6. ftp ls --- EPSV 229 Entering Extended Passive Mode (|||10283|) --- LIST 150 Here comes the directory listing. drwxrwxr-x 265 6060 48 8192 May 05 15:12 concluded-wg-ietf-mail-archive .. and ftp ls --- EPRT |2|2002:c014:e128::1|56420| 200 EPRT command successful. Consider using EPSV. --- LIST 150 Here comes the directory listing. drwxrwxr-x 265 6060 48 8192 May 05 15:12 concluded-wg-ietf-mail-archive .. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
On Jun 11, 2006, at 20:00, IETF Secretariat wrote: All, As you’re all aware, on 06/06/06 NSS successfully launched IPv6 services for IETF Web, Mail, and FTP. Has anyone had FTP work for them when not in passive mode since this configuration change was made? My site's got a clunky old ftp-based mirror script in use which at first glance doesn't seem to know anything about passive mode, and it hasn't fetched any new RFCs since a month ago. Running ftp directly (over ipv4, from a couple of machines, one of which has no ipv6 configuration and no recent software changes) doesn't work either, commands like LIST get back failed to establish connection immediately. I'm probably going to throw away the mirror script anyway and switch to rsync, but I'm still curious to know whether this is some weird problem with our configuration (maybe a surprise related to the ipv6 changes?), or an intentional (but unannounced?) or unintentional configuration change in ftp support at the server side Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
FTP over IPv4 stopped working for me about four weeks ago. Like you, I get 'failed to establish connection' immediately. I flagged it as a problem and have had no response. I can access shadow sites ok Tom Petch - Original Message - From: Ken Raeburn [EMAIL PROTECTED] To: ietf Mailing List ietf@ietf.org Cc: [EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 3:55 PM Subject: Re: IETF IPv6 platform configuration On Jun 11, 2006, at 20:00, IETF Secretariat wrote: All, As you’re all aware, on 06/06/06 NSS successfully launched IPv6 services for IETF Web, Mail, and FTP. Has anyone had FTP work for them when not in passive mode since this configuration change was made? My site's got a clunky old ftp-based mirror script in use which at first glance doesn't seem to know anything about passive mode, and it hasn't fetched any new RFCs since a month ago. Running ftp directly (over ipv4, from a couple of machines, one of which has no ipv6 configuration and no recent software changes) doesn't work either, commands like LIST get back failed to establish connection immediately. I'm probably going to throw away the mirror script anyway and switch to rsync, but I'm still curious to know whether this is some weird problem with our configuration (maybe a surprise related to the ipv6 changes?), or an intentional (but unannounced?) or unintentional configuration change in ftp support at the server side Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF IPv6 platform configuration
If memory serves me right there is a subway terminal built into the foundation of the Delta International. Where the other end of the subway goes is another matter. -Original Message- From: Ken Raeburn [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 9:55 AM To: ietf Mailing List Cc: [EMAIL PROTECTED] Subject: Re: IETF IPv6 platform configuration On Jun 11, 2006, at 20:00, IETF Secretariat wrote: All, As you’re all aware, on 06/06/06 NSS successfully launched IPv6 services for IETF Web, Mail, and FTP. Has anyone had FTP work for them when not in passive mode since this configuration change was made? My site's got a clunky old ftp-based mirror script in use which at first glance doesn't seem to know anything about passive mode, and it hasn't fetched any new RFCs since a month ago. Running ftp directly (over ipv4, from a couple of machines, one of which has no ipv6 configuration and no recent software changes) doesn't work either, commands like LIST get back failed to establish connection immediately. I'm probably going to throw away the mirror script anyway and switch to rsync, but I'm still curious to know whether this is some weird problem with our configuration (maybe a surprise related to the ipv6 changes?), or an intentional (but unannounced?) or unintentional configuration change in ftp support at the server side Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF IPv6 platform configuration
Agh, replied to the wrong message there in case it was not obvious. I was not suggesting using the subway in the hotel as an IPv6 platform. -Original Message- From: Hallam-Baker, Phillip Sent: Wednesday, July 05, 2006 3:52 PM To: 'Ken Raeburn'; ietf Mailing List Cc: [EMAIL PROTECTED] Subject: RE: IETF IPv6 platform configuration If memory serves me right there is a subway terminal built into the foundation of the Delta International. Where the other end of the subway goes is another matter. -Original Message- From: Ken Raeburn [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 9:55 AM To: ietf Mailing List Cc: [EMAIL PROTECTED] Subject: Re: IETF IPv6 platform configuration On Jun 11, 2006, at 20:00, IETF Secretariat wrote: All, As you’re all aware, on 06/06/06 NSS successfully launched IPv6 services for IETF Web, Mail, and FTP. Has anyone had FTP work for them when not in passive mode since this configuration change was made? My site's got a clunky old ftp-based mirror script in use which at first glance doesn't seem to know anything about passive mode, and it hasn't fetched any new RFCs since a month ago. Running ftp directly (over ipv4, from a couple of machines, one of which has no ipv6 configuration and no recent software changes) doesn't work either, commands like LIST get back failed to establish connection immediately. I'm probably going to throw away the mirror script anyway and switch to rsync, but I'm still curious to know whether this is some weird problem with our configuration (maybe a surprise related to the ipv6 changes?), or an intentional (but unannounced?) or unintentional configuration change in ftp support at the server side Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF IPv6 platform configuration
On Wednesday, July 05, 2006 12:53:59 PM -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Agh, replied to the wrong message there in case it was not obvious. I was not suggesting using the subway in the hotel as an IPv6 platform. -Original Message- From: Hallam-Baker, Phillip Sent: Wednesday, July 05, 2006 3:52 PM To: 'Ken Raeburn'; ietf Mailing List Cc: [EMAIL PROTECTED] Subject: RE: IETF IPv6 platform configuration If memory serves me right there is a subway terminal built into the foundation of the Delta International. Where the other end of the subway goes is another matter. I recently looked into the subway situation in Montreal. The Palais des Congress, the Delta, and the main rail station are consecutive subway stops on the same line. They all also appear to be connected by underground tunnels; in fact, it's unclear to me whether using the subway would actually be shorter or faster than walking. IIRC, there is a bus terminal across the street from the rail station. I have no idea if this is the right terminal for people coming in from the airport. Myself, I plan to arrive by rail. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
All, Thank you for your feedback and request. By default, our practice is to disable these functions until there is a justified need/request. We have enabled ICMP echo, ICMP traceroute, and UDP traceroute. Once again, we encourage and look forward to your responses and requests. The IETF Secretariat. -Original Message- From: Joe Touch [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 11:56 AM To: Iljitsch van Beijnum Cc: [EMAIL PROTECTED]; Mark Andrews; ietf@ietf.org Subject: Re: IETF IPv6 platform configuration Iljitsch van Beijnum wrote: On 15-jun-2006, at 1:51, Mark Andrews wrote: *Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 Native firewall (pings, traceroutes etc. are dropped) Why? Shouldn't we be prompting good firewall practices? Droping ICMP was a knee jerk reaction to ICMP echo to directed broadcast addresses. Modern routers can be configured to drop directed broadcast packets. And all of this doesn't even apply to IPv6, it doesn't even support broadcasts in general or anything resembling directed broadcast. ICMP replies are also supposed to be rate limited in IPv6. IPv4 too. There are other reasons to drop them at firewalls (net mapping, protecting other protocols), but I agree we ought to be an example of the best the Internet can provide, not the most paranoid. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
On 15-jun-2006, at 1:51, Mark Andrews wrote: * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 Native firewall (pings, traceroutes etc. are dropped) Why? Shouldn't we be prompting good firewall practices? Droping ICMP was a knee jerk reaction to ICMP echo to directed broadcast addresses. Modern routers can be configured to drop directed broadcast packets. And all of this doesn't even apply to IPv6, it doesn't even support broadcasts in general or anything resembling directed broadcast. ICMP replies are also supposed to be rate limited in IPv6. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
Iljitsch van Beijnum wrote: On 15-jun-2006, at 1:51, Mark Andrews wrote: *Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 Native firewall (pings, traceroutes etc. are dropped) Why? Shouldn't we be prompting good firewall practices? Droping ICMP was a knee jerk reaction to ICMP echo to directed broadcast addresses. Modern routers can be configured to drop directed broadcast packets. And all of this doesn't even apply to IPv6, it doesn't even support broadcasts in general or anything resembling directed broadcast. ICMP replies are also supposed to be rate limited in IPv6. IPv4 too. There are other reasons to drop them at firewalls (net mapping, protecting other protocols), but I agree we ought to be an example of the best the Internet can provide, not the most paranoid. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF IPv6 platform configuration
All, As you’re all aware, on 06/06/06 NSS successfully launched IPv6 services for IETF Web, Mail, and FTP. Following the introduction, NSS received a few technical questions pertaining to IPv6 services. Below you will find technical information as it pertains to configuration and troubleshooting. In addition, NSS is in the process of providing statistics on IPv4 vs. IPv6 that will be posted on the IETF website. IETF IPv6 platform configuration * The IPv6 access to and from IETF is tunneled from a local edge router over IPv4 to a global Internet2 backbone. * All services run native IPv6 in a dual stack configuration. * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 Native firewall (pings, traceroutes etc. are dropped) * All services and devices are monitored and logged. * Interdomain IPv6 is dependant upon DNS caching (specifically the amount of time the global DNS is permitted to remember which IP addresses are assigned within any given domain. This is controlled with TTL values set on the authoritative DNS servers) * eMail service supports messaging between IPv4 and IPv6, and will prefer IPv6 if available. Note: All IPv6 addresses are temporary. New static addresses have been requested and will be implemented in the next few weeks. IETF IPv6 Platform Troubleshooting • Verify your local DNS client receives the following DNS answers from your local DNS server: ietf.org IN NS ns1.neustar.com. ns1.neustar.com IN 2001:503:c779:1a::9c9a:108a ietf.org IN MX 10 stiedprmail1.ietf.org. stiedprmail1.ietf.org IN 2001:503:c779:1a::9c9a:1096 www.ietf.org IN 2001:503:c779:b::d1ad:35b4 ftp.ietf.org IN 2001:503:c779:1a::9c9a:1095 * Verify connectivity as follows: telnet 2001:503:c779:b::d1ad:35b4 80 telnet 2001:503:c779:1a::9c9a:1096 25 ftp 2001:503:c779:1a::9c9a:1095 The IETF Secretariat. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
* Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 Native firewall (pings, traceroutes etc. are dropped) Why? Shouldn't we be prompting good firewall practices? Droping ICMP was a knee jerk reaction to ICMP echo to directed broadcast addresses. Modern routers can be configured to drop directed broadcast packets. The need to block ICMP has long gone. All it does is make debugging the network harder. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
secIETF == IETF Secretariat [EMAIL PROTECTED] writes: secIETF * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 secIETF Native firewall (pings, traceroutes etc. are dropped) Please make sure that ICMP messages needed for path MTU discovery are not filtered. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
Sam Hartman wrote: secIETF == IETF Secretariat [EMAIL PROTECTED] writes: secIETF * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 secIETF Native firewall (pings, traceroutes etc. are dropped) Please make sure that ICMP messages needed for path MTU discovery are not filtered. Is there a compelling reason to filter ICMP at all? - Kevin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
On Mon, 12 Jun 2006, Kevin Loch wrote: Sam Hartman wrote: secIETF == IETF Secretariat [EMAIL PROTECTED] writes: secIETF * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 secIETF Native firewall (pings, traceroutes etc. are dropped) Please make sure that ICMP messages needed for path MTU discovery are not filtered. Is there a compelling reason to filter ICMP at all? IMHO, this is a valid question. There also happens to be a document, draft-ietf-v6ops-icmpv6-filtering-recs-00.txt that discusses this very issue. It might be interesting to have folks read that and provide feedback to v6ops list (v6ops@ops.ietf.org) if they think there's something amiss with it. The document just passed WG LC. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
Kevin Loch wrote: Sam Hartman wrote: secIETF == IETF Secretariat [EMAIL PROTECTED] writes: secIETF *Only HTTP, SMTP, FTP, and DNS traffic are permitted through an IPv6 secIETF Native firewall (pings, traceroutes etc. are dropped) Please make sure that ICMP messages needed for path MTU discovery are not filtered. Is there a compelling reason to filter ICMP at all? - Kevin This is not a trivial problem. There is a draft in progress which recommends what the v6ops wg believes ought to happen. See http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-00.txt This does include making sure Packet Too Big errors are not dropped so that PMTU works, This is just about to very slightly updated but it is essentially finished. It would be good if we ate our own dogfood in this case (and we can also test whether the draft has the answers right!) Regards, Elwyn ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/iet ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
