Subject: IETF IPv6 platform configuration

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.

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

---

From: IETF Secretariat <[email-masked]>
Date: Fri, 16 Jun 2006 15:31:18 -0400

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-masked]] 
   > Sent: Thursday, June 15, 2006 11:56 AM
   > To: Iljitsch van Beijnum
   > Cc: [email-masked]; Mark Andrews; [email-masked]
   > Subject: Re: IETF IPv6 platform configuration
   > 
   > 
   > 
   > Iljitsch van Beijnum wrote:
   > > On 15-jun-2006, at 1:51, Mark Andrews wrote:
   > > 
   > >>
   > >>     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
   > 
   >