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
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
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
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 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" 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
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
