Subject: [v6ops] v6-only (with NAT64) as default network during a conference?

From: Richard Hartmann <[email-masked]>
Date: Wed, 22 Jan 2014 23:37:47 +0100

Dear all,

we (FOSDEM) are currently planning details of our WiFi setup during
the upcoming edition.

We already decided that we would like to run one dual-stack and one
v6-only network with NAT64.

The question is which option should be the default.

>From what I have been told, IETF, RIPE, and TREX has had conferences
with v6-only default networks, but those are geared towards netop and
neteng people; from what we know, we would be the first conference
with a different target audience.

Obviously, our primary goal is to provide infrastructure for a smooth
conference experience.
On the other hand, this is one of very few opportunities where we can
put developers, which came together to solve and discuss issues, into
a real-world v6 scenario.
Prodding people to fix issues is good; making them victims of failure
scenarios outside of their control... not so much.

Long story short: Is this feasible today? What problems should we, or
our users, anticipate? Or should we play it safe, default to
dual-stack, and not have horror stories about v6 propagate?

Thanks,
Richard

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jan 2014 14:56:34 -0800

> dual-stack, and not have horror stories about v6 propagate?

I guess it depends how much breakage you're willing to accept. Browser
stuff will generally be fine, but some applications (e.g., skype, various
video chat apps, SIP clients, some instant messengers etc. etc.) won't work
at all without IPv4. Some hosts, like Android, don't support IPv6-only
networks at all.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2014 20:29:05 -0500

We've had a production quality NAT64 network at the past two IETFs, and it's worked wonderfully.   However, some things do break.   In particular, Skype doesn't work, and I've heard reports that some Cisco VPN implementation doesn't work.   I've found that OpenVPN does work, but needs to be configured differently because it can't automatically switch to IPv6 when IPv4 isn't available—it has to be configured to do one or the other.

If it were up to me, I'd make NAT64 the default and let people switch away if they can't make it work, because particularly at an open source conference I would expect this to generate a lot of frenetic bug fixing rather than a sad migration.   In theory free operating systems ought to do IPv6 better, but your milage may, unfortunately, vary.

---

From: George Michaelson <[email-masked]>
Date: Thu, 23 Jan 2014 11:35:58 +1000

naively, it would be lovely if we could do what an RIR has done, and secure
alternate SIM for use within a limited horizon and price point, which will
do 64XLAT for those of us who have Android 4.x enabled devices.

I don't know if thats possible in all places, but there are Telco's who
seem to be prepared to play nice with us. I feel back in the 802.11b days,
we kind of did this with the loaner-stock cards, and the emerging wifi
network.

otherwise yes, I agree. with some fallback proviso, making the default
NAT64 would be interesting.

On Thu, Jan 23, 2014 at 11:29 AM, Ted Lemon <[email-masked]> wrote:

> We've had a production quality NAT64 network at the past two IETFs, and
> it's worked wonderfully.   However, some things do break.   In particular,
> Skype doesn't work, and I've heard reports that some Cisco VPN
> implementation doesn't work.   I've found that OpenVPN does work, but needs
> to be configured differently because it can't automatically switch to IPv6
> when IPv4 isn't available—it has to be configured to do one or the other.
>
> If it were up to me, I'd make NAT64 the default and let people switch away
> if they can't make it work, because particularly at an open source
> conference I would expect this to generate a lot of frenetic bug fixing
> rather than a sad migration.   In theory free operating systems ought to do
> IPv6 better, but your milage may, unfortunately, vary.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Cb B <[email-masked]>
Date: Wed, 22 Jan 2014 17:41:08 -0800

>
> If it were up to me, I'd make NAT64 the default and let people switch
away if they can't make it work, because particularly at an open source
conference I would expect this to generate a lot of frenetic bug fixing
rather than a sad migration.   In theory free operating systems ought to do
IPv6 better, but your milage may, unfortunately, vary.

+1 for nat64 default with another ssid for dual-stack.  This should be a
good practice for ietf, nanog, rirs, and so on.

This is the obvious way of things to come given the post ipv4 run out
situation we are currently living.

CB _______________________________________________

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2014 20:42:37 -0500

On Jan 22, 2014, at 8:35 PM, George Michaelson <[email-masked]> wrote:
> naively, it would be lovely if we could do what an RIR has done, and secure alternate SIM for use within a limited horizon and price point, which will do 64XLAT for those of us who have Android 4.x enabled devices.

I don't think doing 464XLAT is interesting on the IETF network, because it looks just like an IPv4 NATTed network to the host (with some NAT traversal technology potentially broken).

The point of setting up an IPv6-only network is to discover what breaks, and hopefully to get people used to using IPv6, if it mostly doesn't break.   The point of enabling NAT64 is that it is more likely to reveal than conceal breakage, and additionally makes it possible to actually use the network, which is still a bit difficult on the completely v6-only network, more's the pity.

---

From: George Michaelson <[email-masked]>
Date: Thu, 23 Jan 2014 11:48:35 +1000

A good point, and diluting focus is often not useful. But I do note that
mobile device access is probably the most visible uptake we have now
worldwide, and its somewhat amusing how little visibility that has inside
IETF. I suspect the verizon customer base aside, few of the attendees
realize half or more of the room could have been using V6 on the telephony
radio spectrum, given a chance.

And you do note there are also risks of breakage in '(with some NAT
traversal technology potentially broken).' but I take your main point: the
goal is to test what breaks, and NAT64 is probably the best path to do that
while keeping a useful net.

Aren't the VPN failure modes you mention in the NAT64 case also plausible
examples which will break in a 464XLAT case?

On Thu, Jan 23, 2014 at 11:42 AM, Ted Lemon <[email-masked]> wrote:

> > naively, it would be lovely if we could do what an RIR has done, and
> secure alternate SIM for use within a limited horizon and price point,
> which will do 64XLAT for those of us who have Android 4.x enabled devices.
>
> I don't think doing 464XLAT is interesting on the IETF network, because it
> looks just like an IPv4 NATTed network to the host (with some NAT traversal
> technology potentially broken).
>
> The point of setting up an IPv6-only network is to discover what breaks,
> and hopefully to get people used to using IPv6, if it mostly doesn't break.
>   The point of enabling NAT64 is that it is more likely to reveal than
> conceal breakage, and additionally makes it possible to actually use the
> network, which is still a bit difficult on the completely v6-only network,
> more's the pity.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2014 20:57:42 -0500

On Jan 22, 2014, at 8:48 PM, George Michaelson <[email-masked]> wrote:
> Aren't the VPN failure modes you mention in the NAT64 case also plausible examples which will break in a 464XLAT case?

It depends.   Often the bug in these cases is not in the bits on the wire, but in the way the application uses the kernel plumbing.   I think that's why 464xlat sometimes succeeds where NAT64 doesn't.

---

From: Gert Doering <[email-masked]>
Date: Thu, 23 Jan 2014 10:08:58 +0100

Hi,

> examples which will break in a 464XLAT case?

OpenVPN will not work if you force it to use 464xlat by connecting to an
IPv4 literal.

OTOH, the *Android* build of OpenVPN handles automatic failover from 
IPv4 to IPv6 just fine, so if you point your VPN client at the server's 
host name, NAT64 will do it's job.  So the 464xlat case is only relevant
if you put an IPv4 literal into your configs, and you're not supposed
to do that anyway...

The issue with NAT64 and OpenVPN affects the 2.3.x releases for "classic"
OSes (MacOS, Linux, Windows) - this one has no AFI failover support, so
it will be "IPv4-only" or "IPv6-only", and you need to manually change
the AFI used if behind a NAT64.  Then it will also work.  (Fixed in 
git master, to be released as 2.4.0 eventually)

Can't say anything about Cisco VPN client or any of the other ones
floating around.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Czerwonka Michał - Hurt <[email-masked]>
Date: Thu, 23 Jan 2014 16:24:05 +0000

Hi,

we use 464xlat for IPv6-only access, but without DNS64 and most of problem are gone.
In this scenario CLAT+NAT64+DNS-DualStack, Cisco VPN client works fine. It does not matter if the server is ipv4 literal or ipv4 domain. Of course NAT-T (IPSEC/UDP) is enabled, because android-clat does not process packet of ESP protocol. 

BR,
mcz

-----Wiadomość oryginalna-----
Od: v6ops [mailto:[email-masked]] W imieniu Gert Doering
Wysłano: 23 stycznia 2014 10:09
Do: George Michaelson
DW: IPv6 Operations
Temat: Re: [v6ops] v6-only (with NAT64) as default network during a conference?

Hi,

Gert Doering
        -- NetMaster

---

From: <[email-masked]>
Date: Thu, 23 Jan 2014 17:27:16 +0100

Hello *,

I've been running the v6-only WiFi scenario in our department for quite a while so that colleagues can get a feeling on how well v6-only works with NAT64. This is a good thing to showcase IPv6 with one of the "IPv4 compatibility modes", but as already discussed here, some stuff will not work and you know that right from the start, so the question is, do you want to make the participants aware of this right from the start, or should they discover this themselves?

One major thing I found was that some devices (especially Apple iPhone) consider a physical connection only "up" if the interface gets an IPv4 address, otherwise, the OS takes the interface down and retries (scanning for a different SSID or whatever) even an IPv6 address was there. So I had to also hand out fake IPv4 addresses to satisfy these devices, but block all IPv4 communication. Not nice. Probably you could do the same and redirect all IPv4 traffic to an error page telling participants what to do (of course, this will only work with HTTP traffic).

Holger

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von Richard Hartmann
Gesendet: Mittwoch, 22. Januar 2014 23:38
An: IPv6 Operations
Betreff: [v6ops] v6-only (with NAT64) as default network during a conference?

Dear all,

we (FOSDEM) are currently planning details of our WiFi setup during the upcoming edition.

We already decided that we would like to run one dual-stack and one v6-only network with NAT64.

>From what I have been told, IETF, RIPE, and TREX has had conferences with v6-only default networks, but those are geared towards netop and neteng people; from what we know, we would be the first conference with a different target audience.

Obviously, our primary goal is to provide infrastructure for a smooth conference experience.
On the other hand, this is one of very few opportunities where we can put developers, which came together to solve and discuss issues, into a real-world v6 scenario.
Prodding people to fix issues is good; making them victims of failure scenarios outside of their control... not so much.

Long story short: Is this feasible today? What problems should we, or our users, anticipate? Or should we play it safe, default to dual-stack, and not have horror stories about v6 propagate?

Thanks,
Richard