Subject: Re: IPv6 @ IETF-71, especially Jabber

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 Mar 2008 11:12:46 +0100

On 29 feb 2008, at 15:34, Iljitsch van Beijnum wrote:

> What's going on with the preparations to turn off IPv4 at IETF-71?
> It's been really quiet surrounding that topic since the initial
> discussion.

It's good to hear that work is going on behind the scenes.

> So... does anyone know a place to obtain a Jabber account that's
> usable over IPv6? I assumed psg.com would be a good candidate, but
> even though psg.com has a AAAA record, jabber.psg.com doesn't.

I've had a couple of offers in private email (thanks for those!) but  
I've decided to go into another direction with this, and set up a  
transport relay translator (RFC3142) on a FreeBSD server. This is a  
combination special network interface and a daemon that listens on an  
IPv6 TCP port and forwards the session to the IPv4 destination encoded  
in the low bits of the IPv6 address. See the faithd man page

For the next two weeks, the translator will be open for everyone on  
prefix 2001:1af8:5:f::/96 on ports 5222 and 5223. So if, like me, you  
use Google Talk for Jabber you can connect to 2001:1af8:5:f:: 
209.85.137.125 (or 2001:1af8:5:f::d155:897d) rather than  
209.85.137.125. (Replace the IPv4 bits with that of your Jabber server  
if you use another Jabber server.) This has of course the slight  
downside that you can only use Jabber when you have IPv6 connectivity.  
I fixed this by setting up a hostname that has both the translated  
address and the normal address: googletalk.runningipv6.net.

A side effect is that the SSL certificate now doesn't match the  
hostname, so you'll get an SSL warning (or failure). As long as you  
manually check the certificate you SHOULD still be secure, but your  
milage may vary.

Connecting to Google Talk in this manner allowed me to use Jabber as  
usual (as you can see if you go to v6ops @ jabber.ietf.org), when  
running dual stack, IPv6 only or IPv4 only. I used iChat with the  
caveat in described an earlier message and Adium without any problems  
on the Mac.

Note that all the above becomes moot if there is a NAT-PT translator  
and a DNS ALG when IPv4 is turned off.

I've also tried some clients on Windows XP, but no success with  
those... Too bad, because having working Jabber should be very helpful  
in debugging all the other protocols that may have issues when running  
IPv6-only. In this case NAT-PT will NOT help because of XP's inability  
to resolve DNS names over IPv6.

I'm on Jabber as iljitsch @ gmail.com if anyone needs assistence with  
any of this.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 05 Mar 2008 10:09:53 -0500

As mentioned last week -- the wiki is now accessible:

http://wiki.tools.isoc.org/IETF71_IPv4_Outage

Thanks,
Leslie.

Leslie Daigle wrote:
> 
> Hi,
> 
> To the basic question of the IPv4 outage -- preparations are
> indeed underway, to implement it as Russ described on 12/22/2007[1].
> 
> Early next week, there will be a wiki page accessible specifically
> for our event, providing more detail and more pointers.  In the
> meantime, if you have specific comments, you can send comments to
> the team Russ set up[2].
> 
> In the meantime, NANOG and APRICOT have had similar events.  You
> can see some of the data captured here:
> 
> http://www.civil-tongue.net/grandx/
> 
> and some writeups:
> 
> http://www.networkworld.com/community/node/25276
> http://www.circleid.com/posts/82283_ipv6_hour_ipv4_switched_off/
> 
> 
> Leslie.
> 
> 
> [1]
> [On December 22, 2007, Russ Housley wrote:]
>> Following the mail list discussion, we have considered several different
>> configurations for achieving the desired network experiment environment.
>> It is important that everyone have adequate opportunity for advance
>> configuration, and it is important that severe impact on other network
>> resources at the meeting venue be avoided.  With these goals in mind, we
>> intend to add an additional IPv6-only subnet, with a different SSID on
>> the wireless network.  The SSID will include some clever name that
>> includes the string "v6ONLY".  This SSID will be available on all the
>> wireless access points throughout the venue for the entire week.
>> Everyone is encouraged to try using this network well before the plenary
>> session.  Neighbors and friends are encouraged to help each other debug
>> problems, and the kind folks at the help desk in the Terminal Room will
>> also be happy to assist with any configuration challenges, IPv6-related
>> or otherwise.
> 
> 
> 
> [2] [email-masked]
> 
> 
> 
> Iljitsch van Beijnum wrote:
>> Because I've had an IPv6 mail server for years and a WWW proxy that  
>> allows IPv6-only hosts to get access to the IPv4 web is fairly 
>> trivial  to set up (tip for XP users: XP can't do DNS lookups over 
>> IPv6, use  Firefox and configure it with the IPv6 address of the 
>> proxy), my  preperation for this has been mostly getting Jabber to 
>> work over IPv6.
>>
>> A while ago I managed to find a public Jabber server that is 
>> reachable  over IPv6 (amessage.de with some other domains pointing to 
>> the same  server). Unfortunately, the client I generally use, Apple's 
>> iChat,  does support Jabber over IPv6 when there is IPv4 connectivity, 
>> but  when the system has no IPv4 address it says that "you're not 
>> connected  to the internet" and doesn't try to connect over IPv6. 
>> Recently I  thought this was fixed but it turned out that the 
>> Parallels Desktop  virtualization enviroment sets up a bunch of 
>> virtual interfaces with  private addresses, which is enough for iChat 
>> to work over IPv6.
>>
>> Anyway, I started looking for Jabber clients that support IPv6. Most  
>> don't, but there are so many Jabber clients that there is actually a  
>> choice of ones that do. Unfortunately, none of them could connect to  
>> the jabber.ietf.org rooms. I first thought this was because of the  
>> clients, so I didn't keep a list of clients that support IPv6. But it  
>> turned out that this is a problem with my iljitsch at amessage.nl  
>> account on the amessage.de server, which doesn't seem IPv6-related.
>>

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Mar 2008 11:09:07 +0100

> http://wiki.tools.isoc.org/IETF71_IPv4_Outage

Right, it was accessible yesterday, but not anymore, at least, for me:  
the pages don't load.

Looks like this is hosted on a 6to4 address. This isn't recommended,  
because the quality of 6to4 reachability is highly variable. But  
reachability doesn't seem to be the issue:

$ ping6 -c 4 wiki.tools.isoc.org
PING6(56=40+8+8 bytes) 2001:720:410:1001:21b:63ff:fe92:9fbb -->  
2002:4e2f:6761::2

--- wiki.tools.isoc.org ping6 statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 133.693/133.840/134.106 ms

So this looks like a path MTU discovery black hole. According to a  
traceroute, the web server is terminating the 6to4 link itself and  
this server is announcing a 1420 byte MSS:

10:54:54.464280 IP6 2002:4e2f:6761::2.http > 2001:720:410:1001:21b: 
63ff:fe92:9fbb.49238: S 2106457901:2106457901(0) ack 809912022 win  
5632 <mss 1420,sackOK,timestamp 1184434509 542018613,nop,wscale 7>

This is consistent with a 1500 byte IPv4 MTU - 20 bytes IPv4  
encapsulation = a 1480 byte IPv6 MTU. However, the server is  
unreachable (from where I'm sitting) for 1480 byte packets:

$ ping6 -c 4 -s 1432 wiki.tools.isoc.org
PING6(1480=40+8+1432 bytes) 2001:720:410:1001:21b:63ff:fe92:9fbb -->  
2002:4e2f:6761::2

--- wiki.tools.isoc.org ping6 statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

Can this please be fixed?

In general, people use a 1280 byte MTU for 6to4, which nicely avoids  
the possibility of path MTU discovery black holes.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 06 Mar 2008 06:26:54 -0500

Hi,

Sorry -- I've been on a plane most of the last day.

The problem yesterday was detected & addressed; thanks
for letting me know it's recurring.  I am told that
the problem has been isolated & working on a fix.

Leslie.

Iljitsch van Beijnum wrote:
> traceroute, the web server is terminating the 6to4 link itself and this 
> server is announcing a 1420 byte MSS:
> 
> 10:54:54.464280 IP6 2002:4e2f:6761::2.http > 
> 2001:720:410:1001:21b:63ff:fe92:9fbb.49238: S 2106457901:2106457901(0) 
> ack 809912022 win 5632 <mss 1420,sackOK,timestamp 1184434509 
> 542018613,nop,wscale 7>
> 
> encapsulation = a 1480 byte IPv6 MTU. However, the server is unreachable 
> (from where I'm sitting) for 1480 byte packets:
> 
> In general, people use a 1280 byte MTU for 6to4, which nicely avoids the 
> possibility of path MTU discovery black holes.
> 

--

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 05 Mar 2008 21:28:28 -0500

Hi Leslie,

> http://wiki.tools.isoc.org/IETF71_IPv4_Outage

Currently getting a 503 error from the server.

-- 
Cyrus Daboo

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Mar 2008 09:48:13 +1100

To reach the wiki you need a dual-stack DNS server.

	::1 is running "named -6", i.e. it only talks over IPv6.

	Mark

% dig wiki.tools.isoc.org +vc @::1

; <<>> DiG 9.3.4-P1 <<>> wiki.tools.isoc.org +vc @::1
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46706
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;wiki.tools.isoc.org.           IN      A

;; Query time: 9999 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Mar  7 09:46:50 2008
;; MSG SIZE  rcvd: 37

% 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf