Subject: Re: IETF IPv6 platform configuration

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Jun 2006 14:33:24 -0400

>>>>> "secIETF" == IETF Secretariat <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Kevin Loch <[email-masked]>
Date: Mon, 12 Jun 2006 14:57:42 -0400

> Please make sure that ICMP messages needed for path MTU discovery are

Is there a compelling reason to filter ICMP at all?

- Kevin

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 Jun 2006 00:03:06 +0300 (EEST)

On Mon, 12 Jun 2006, Kevin Loch wrote:
>>     secIETF> *	Only HTTP, SMTP, FTP, and DNS traffic are permitted 
>> through an IPv6     secIETF>         Native firewall (pings, traceroutes 
>> etc. are dropped) 
>> 

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 ([email-masked]) 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 Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 12 Jun 2006 23:07:21 +0100

Kevin Loch wrote:
>> through an IPv6     secIETF>         Native firewall (pings, 
>> traceroutes etc. are dropped) 
>>
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

> https://www1.ietf.org/mailman/listinfo/iet

---

From: IETF Secretariat <[email-masked]>
Date: Sun, 11 Jun 2006 20:00:14 -0400

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 AAAA 2001:503:c779:1a::9c9a:108a

      ietf.org                      IN MX 10 stiedprmail1.ietf.org.

      stiedprmail1.ietf.org         IN AAAA 2001:503:c779:1a::9c9a:1096

      www.ietf.org                  IN AAAA 2001:503:c779:b::d1ad:35b4

      ftp.ietf.org                  IN AAAA 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.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Jun 2006 09:51:21 +1000

>         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-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 Jun 2006 09:28:21 +0200

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Jun 2006 08:56:21 -0700

> 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