Subject: [90attendees] ietf-nat64 working nicely!

From: Ted Lemon <[email-masked]>
Date: Sun, 20 Jul 2014 12:20:27 -0400

My laptop automatically connected to the ietf-nat64 network.   Everything is Just Working--I didn't even know which network I was on until I checked just now.   Very nice.   Thanks to the ops team for making this happen again!

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Jul 2014 14:16:48 -0400

> My laptop automatically connected to the ietf-nat64 network.   Everything is Just Working--I didn't even know which network I was on until I checked just now.   Very nice.   Thanks to the ops team…

Can we make IPv6+NAT64 the default on the IETF meeting network? Please?

Simon

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Jul 2014 14:19:04 -0400

> Can we make IPv6+NAT64 the default on the IETF meeting network?

if we are gonna make nat the default, we should do nat444, as that is
what we are aiding and abeting for the broadband victims.

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 20 Jul 2014 20:19:13 +0200 (CEST)

> Can we make IPv6+NAT64 the default on the IETF meeting network? Please?

Can we at least get all these experimental ones with .1x enabled? I prefer 
not to use unencrypted wifi networks if possible.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Colin Doyle <[email-masked]>
Date: Sun, 20 Jul 2014 11:19:41 -0700

Default?

C

-- 

Colin Doyle
Networking Fellow
Verilan, Inc.
7327 SW Barnes Rd. #215
Portland, OR 97225

+1 503.810.2129 [mobile]
[email-masked] [email]
cdoyle.verilan [skype]
www.verilan.com [website]

This e-mail contains proprietary information and may be confidential. If
you are not the intended recipient of this e-mail, you are hereby notified
that any dissemination, distribution or copying of this message is strictly
prohibited. If you received this message in error, please delete it
immediately.
On Jul 20, 2014 12:17 PM, "Simon Perreault" <[email-masked]> wrote:

> > My laptop automatically connected to the ietf-nat64 network.
> Everything is Just Working--I didn't even know which network I was on until
> I checked just now.   Very nice.   Thanks to the ops team for making this
> happen again!
>
> _______________________________________________
> 90attendees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/90attendees
>

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Jul 2014 14:27:32 -0400

> Default?

For example:

ietf: IPv6, NAT64, no IPv4
ietf-v6only: IPv6, no NAT64, no IPv4
ietf-dual: IPv6, IPv4

The idea would be to make more IETF attendees eat their own dog food.
(The dog food in question being IPv6, not necessarily NAT64.)

Simon

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Jul 2014 14:30:14 -0400

> what we are aiding and abeting for the broadband victims.

v6only as default would be even better, and it would send a much
stronger signal. I doubt its social acceptability among IETF attendees,
but I'd be happy to be proven wrong.

Simon

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Jul 2014 14:36:13 -0400

let me be more clear.  are we trying to provide high quality internet to
conference attendees or hold a religious ceremony?

randy

---

From: Chris Elliott <[email-masked]>
Date: Sun, 20 Jul 2014 14:36:41 -0400

> but I'd be happy to be proven wrong.

The limitation from the hardware side is that there are 8 mac addresses
available on each radio interface on the APs, and we are currently using 8
SSIDs on the 5Ghz radio interfaces:

 ssid <NOC_network>
 ssid eduroam
 ssid ietf
 ssid ietf.1x
 ssid ietf-a
 ssid ietf-a.1x
 ssid ietf-nat64
 ssid ietf-v6ONLY

I'm willing to consider any options within this constraint. I'm not willing
to deploy two sets of APs to get around this constraint.

Chris.

-- 
Chris Elliott
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Jul 2014 14:38:01 -0400

> conference attendees or hold a religious ceremony?

Let me be more clear as well: by continuing to provide IPv4 on the
default IETF meeting network, we are being part of the problem.

Simon

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Sun, 20 Jul 2014 14:38:17 -0400

a little of both: we're the best beta testing crowd imaginable, and it's
something we should take advantage of.

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Jul 2014 14:39:13 -0400

Le 2014-07-20 14:36, Chris Elliott a écrit :
> available on each radio interface on the APs, and we are currently using
> 8 SSIDs on the 5Ghz radio interfaces:
> 
>  ssid <NOC_network>
>  ssid eduroam
>  ssid ietf
>  ssid ietf.1x
>  ssid ietf-a
>  ssid ietf-a.1x
>  ssid ietf-nat64
>  ssid ietf-v6ONLY
> 
> I'm willing to consider any options within this constraint. I'm not
> willing to deploy two sets of APs to get around this constraint.

Understood. The proposal is to swap ietf with either ietf-nat64 or
ietf-v6ONLY. No SSID addition or removal.

Simon

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Jul 2014 14:42:34 -0400

>> let me be more clear.  are we trying to provide high quality internet
>> to conference attendees or hold a religious ceremony?

i am an operator.  providing the internet that users expect is not
considered a problem.  denying services in the name of religion is.

randy

---

From: joel jaeggli <[email-masked]>
Date: Sun, 20 Jul 2014 14:43:01 -0400

On 7/20/14, 2:38 PM, Carlos M. Martinez wrote:
> a little of both: we're the best beta testing crowd imaginable, and
> it's something we should take advantage of.

That's a presumption that doesn't hold water if you test it.

there's a lot of people using the net to get their work done.

>> let me be more clear.  are we trying to provide high quality
>> internet to conference attendees or hold a religious ceremony?
>> 
>> randy
>> 
>> _______________________________________________ 90attendees
>> mailing list [email-masked] 
> _______________________________________________ 90attendees mailing
> list [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Jul 2014 14:43:20 -0400

> something we should take advantage of.

which is why the network makes it available to you.  in all the flavors
that the APs let the noc provide.

randy

---

From: Chris Elliott <[email-masked]>
Date: Sun, 20 Jul 2014 14:43:23 -0400

> default IETF meeting network, we are being part of the problem.

Currently, we /know/ that all IPv6 only solutions do not allow you to do
everything you can do using IPv4. I do not think I'm willing to make the
default network a network that will break things attendees need to do. And,
it wouldn't be effective All that would happen is that people would decide
that SSID <foo> is the default instead of "ietf".

Chris.

-- 
Chris Elliott
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Sun, 20 Jul 2014 14:44:40 -0400

> there's a lot of people using the net to get their work done.

Two responses:

1) There's a lot of people using ietf-nat64 and ietf-v6ONLY to get work
done. IPv6 does work, you know?

2) If you really do need real IPv4, just use ietf-dual. The proposal is
not to take it away, it's about what the default is.

Simon

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Jul 2014 14:49:06 -0400

> 2) If you really do need real IPv4, just use ietf-dual. The proposal
> is not to take it away, it's about what the default is.

the ops view is that the default is to let people get their work done

[ you may, or may not, remember that i am the one who jumped up and down
  to get 6/4 nat back into the ietf.  most of my $dayjob customers are
  enterprise. ]

randy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 20 Jul 2014 20:49:43 +0200 (CEST)

> to deploy two sets of APs to get around this constraint.

Could we please do the ietf/ietf username/password combination on .1x for 
all the currently unencrypted ones?

---

From: George Michaelson <[email-masked]>
Date: Sun, 20 Jul 2014 15:01:11 -0400

It being understood this is not a democracy and all opinions are not equal,
I would be fine with the IETF deciding to break the default net given a
non-default was not broken.

ie, I understand Randys joker-card override 'ops means works' but I think
this is an opportunity to think different. I also think that just because
the cabal of ops said "A" is probably the best reason we have to say "f**k
you" and chose "B" but then we'd have to pick up the pieces. which, since
they don't share root, is impossible. So lets admit reality here.

"he who has root makes the rules"

chuss

-G

On Sun, Jul 20, 2014 at 2:49 PM, Mikael Abrahamsson <[email-masked]>
wrote:

> willing

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Sun, 20 Jul 2014 15:13:41 -0400

In the end, default here means 'whatever you have higher up in your WLAN
list', so, if you really care about getting work that won't 'work' over
ipv6+nat64, you can just 'switch defaults'. This would probably too much
to ask from my mother, but I guess ietf folk know how to tweak this.

Setting a different 'default default' provides a wider testing base, not
to mention it's also keeping up our word that we eat our own dog food
while not taking much away from those who have things that really,
really break over nat64.

So far, the experiment of nat64 is one of 'someone says it works', plus
other voices saying 'my el-raro-file-sync service fails'.

Think of it as an A|B testing experiment. Default everyone to
ipv6+nat64, measure how many use it, and by the end of the week measure
how many folks actually switched defaults to ipv6-dual.

cheers,

=Carlos

On 7/20/14, 3:01 PM, George Michaelson wrote:
> It being understood this is not a democracy and all opinions are not
> equal, I would be fine with the IETF deciding to break the default net
> given a non-default was not broken.
>
> ie, I understand Randys joker-card override 'ops means works' but I
> think this is an opportunity to think different. I also think that
> just because the cabal of ops said "A" is probably the best reason we
> have to say "f**k you" and chose "B" but then we'd have to pick up the
> pieces. which, since they don't share root, is impossible. So lets
> admit reality here.
>
> On Sun, Jul 20, 2014 at 2:49 PM, Mikael Abrahamsson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Jen Linkova <[email-masked]>
Date: Sun, 20 Jul 2014 21:27:18 +0200

On Sun, Jul 20, 2014 at 9:13 PM, Carlos M. Martinez <[email-masked]> wrote:
> ipv6+nat64, you can just 'switch defaults'. This would probably too much to
> ask from my mother, but I guess ietf folk know how to tweak this.

Exactly. I'm not sure I even understand the problem statement. I just
have 'v6-only' as a top preference and then I have v6+nat64. It does
allow me to get my work done and works fine for 99.9% of non-work
related cases.

-- 
SY, Jen Linkova aka Furry

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Sun, 20 Jul 2014 15:44:22 -0400

it's a fact that most people will use the default, so even in the cases
where the non-default setting will work for 99.9% of all involved, there
is simply no incentive or push to switch to the 'new' thing, and it will
not get widely used. Just because it is not the default.

Similar with what happens if you publish your perfectly-working AAAA
record for your perfectly working-over-ipv6 website under the name
'ipv6.whatever.com'. No one, except those looking for it, will use it.
That's why you do this for a while, before going full monty and turning
on AAAA's for 'www.whatever.com'.

It's a matter of creating critical mass, to find out and iron out the
bugs that are not caught in the limited testing allowed by the 'new'
thing not being the default.

I've intentionally avoided to use SSID names here because I believe this
argument applies for well, mostly anything.

cheers!

-Carlos

---

From: Alejandro Acosta <[email-masked]>
Date: Sun, 20 Jul 2014 15:37:01 -0430

> default IETF meeting network, we are being part of the problem.

One more option (not saying is good or bad):

What about not having a default network?.., just explicit networks that
can be identify by the SSID name

---

From: David Lamparter <[email-masked]>
Date: Sun, 20 Jul 2014 22:37:55 +0200

> SSIDs on the 5Ghz radio interfaces:
[snip]
> to deploy two sets of APs to get around this constraint.

We distinguished networks on .1X by login name at 30C3.  I believe that
worked by the RADIUS in the back sending a VLAN attr, and the wifi
controller's magic supported that.

Done correctly, this means you ever only need 1 .1X SSID for each set of
radio parameters (we still had a 5GHz-only .1X SSID plus an all-band
one).

-David

---

From: Stuart Cheshire <[email-masked]>
Date: Sun, 20 Jul 2014 13:41:28 -0700

On 20 Jul, 2014, at 11:36, Randy Bush <[email-masked]> wrote:

> let me be more clear.  are we trying to provide high quality internet to conference attendees or hold a religious ceremony?

IETF meetings also serve a third function: Education. I always hope to leave IETF meetings knowing more than I did when I arrived.

Many meetings ago Marc Blanchet tapped me on the shoulder and suggested I try out the IETF-NAT64 network. I did. It took only a couple of minutes of my time to try it out. Most things on my iPhone worked fine. In fact I was amazed at how much stuff worked perfectly. A few minor things did not work perfectly. I filed bug reports for those, and iOS was improved as a result. And this happened because people like Marc Blanchet had worked to make NAT64 available at an IETF meeting so that people like me could easily try it out. This was a good outcome.

I would support making IPv6 with NAT64 be the default IETF meeting service, because as time goes on this is likely to be the only network many residential customers have, so our community needs to be knowledgeable about how well such networks work. For people who still need native IPv4 (hopefully a dwindling minority) there should also be an “IETF-Legacy” SSID that provides both native IPv4 and native IPv6.

As an aside, I just tried using a Google Nexus 5 running Android 4.4.4, and it refused to use the “IETF-NAT64” network, helpfully telling me that it had “Avoided poor Internet connection.”

Any other Android users seen this on the “IETF-NAT64” network?

Stuart Cheshire

---

From: Ted Lemon <[email-masked]>
Date: Sun, 20 Jul 2014 18:13:48 -0400

> but I'd be happy to be proven wrong.

The network has to be usable.   Since there is a lot of stuff we need that's still only available via IPv4, we still need a way to get to the IPv4 internet by default.   So no, v6-only should not be the default.

---

From: Shumon Huque <[email-masked]>
Date: Sun, 20 Jul 2014 19:53:31 -0400

> but I'd be happy to be proven wrong.

Don't forget that for those of us doing DNSSEC validation on our
endstations or applications, NAT64/DNS64 will render IPv4 only sites in
signed DNS zones unreachable.

--Shumon.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 20 Jul 2014 20:59:14 -0400

On Sun, Jul 20, 2014 at 12:20:27PM -0400,
 Ted Lemon <[email-masked]> wrote 
 a message of 7 lines which said:

> Everything is Just Working--I didn't even know which network I was
> on until I checked just now.

I used NAT64 for IETF and RIPE meetings several times and, since it
worked, I decided to try riskier things :-) Today, I had unfortunately
zero success with BitTorrent (clients rtorrent and
transmission). Giving that the protocol sends back referrals to IP
addresses, I'm afraid it cannot work over NAT64. But, if anyone has a
better idea?

But may be my use of BitTorrent does not fit Randy's definition of
"getting work done" :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 20 Jul 2014 20:56:16 -0400

On Sun, Jul 20, 2014 at 01:41:28PM -0700,
 Stuart Cheshire <[email-masked]> wrote 
 a message of 1487 lines which said:

> As an aside, I just tried using a Google Nexus 5 running Android
> 4.4.4, and it refused to use the “IETF-NAT64” network, helpfully
> telling me that it had “Avoided poor Internet connection.”
> 

Apparently (not enough time to be sure) no problem for me on a Wiko
running Android 4.2.2. I had bad experiences with previous versions of
Android on NAT64, because Android insisted to get an IPv4
address. Now, it is apparently happy with only an IPv6 one.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Jul 2014 21:41:21 -0400

On 20 Jul 2014, at 15:13, Carlos M. Martinez <[email-masked]> wrote:

> A|B testing experiment

Make it a one-day experiment then.
(Announce it at the technical plenary.)

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Sun, 20 Jul 2014 21:56:02 -0400

On Jul 20, 2014, at 8:59 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> Giving that the protocol sends back referrals to IP

I'm surprised that it didn't work over plain IPv6.   Have you tried it on the -v6only network?

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Jul 2014 07:10:20 -0400

> signed DNS zones unreachable.

Not true.

http://tools.ietf.org/html/rfc6147#section-6.2
http://tools.ietf.org/html/rfc7050

Simon

---

From: Randy Bush <[email-masked]>
Date: Mon, 21 Jul 2014 07:56:20 -0400

> But may be my use of BitTorrent does not fit Randy's definition of

i live and die by btsync, research groups, travel reports, ...

---

From: Randy Bush <[email-masked]>
Date: Mon, 21 Jul 2014 07:56:59 -0400

> (Announce it at the technical plenary.)

we did that years ago

---

From: Tim Chown <[email-masked]>
Date: Mon, 21 Jul 2014 13:15:16 +0100

I think Stuart’s comments below are excellent.

If IPv6+NAT64 were the default, there can still be an 'ietf-v4' SSID made available for those who want IPv4-only.  The question is what the default ‘ietf’ SSID should provide.  I don’t think anyone is suggesting removing what is currently the default altogether.

Tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 21 Jul 2014 08:03:13 -0400

On Sun, Jul 20, 2014 at 09:56:02PM -0400,
 Ted Lemon <[email-masked]> wrote 
 a message of 8 lines which said:

> I'm surprised that it didn't work over plain IPv6. 

I tested only with IPv4-only trackers.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 21 Jul 2014 08:21:58 -0400

> http://tools.ietf.org/html/rfc7050

Ah, so I have to implement the DNS64 function on my endstation. I think I'm
staying on the dual stack network :-)

Alternatively, if one were to decide to delegate validation to the DNS64
proxy, does the IETF network's current implementation support a transaction
security mechanism that could be used? (eg. per-user symmetric key TSIG  or
SIG(0))?

--Shumon.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Jul 2014 08:34:52 -0400

On Jul 21, 2014, at 8:21 AM, Shumon Huque <[email-masked]> wrote:
> Ah, so I have to implement the DNS64 function on my endstation. I think I'm staying on the dual stack network :-)

Setting up DNS64 isn't terribly difficult, but it's certainly true that it's not sufficiently automatic in current distributions.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Jul 2014 08:57:00 -0400

Le 2014-07-21 08:21, Shumon Huque a écrit :
> Ah, so I have to implement the DNS64 function on my endstation. I think
> I'm staying on the dual stack network :-)

Just use a local DNS recursive nameserver. I prefer Unbound for that
purpose. The only missing part is having NetworkManager start it
automatically. I suppose one could hack that up with a hook script.

> proxy, does the IETF network's current implementation support a
> transaction security mechanism that could be used? (eg. per-user
> symmetric key TSIG  or SIG(0))?

No idea.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 21 Jul 2014 08:57:54 -0400

>> (Announce it at the technical plenary.)

Actually what we did was an IPv6-only experiment (no NAT64), and it only
lasted during the plenary.

Simon

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 21 Jul 2014 09:04:31 -0400

Le 2014-07-21 à 08:21, Shumon Huque <[email-masked]> a écrit :

> On Mon, Jul 21, 2014 at 7:10 AM, Simon Perreault <[email-masked]> wrote:
> Alternatively, if one were to decide to delegate validation to the DNS64 proxy, does the IETF network's current implementation support a transaction security mechanism that could be used? (eg. per-user symmetric key TSIG  or SIG(0))?

but this is not related to DNS64, but instead related to the validation.  Do I do my own dnssec validation (on the host) or do I trust someone else to do it for me?  

Regards, Marc.

---

From: Randy Bush <[email-masked]>
Date: Mon, 21 Jul 2014 09:05:37 -0400

i confuse between ietf and nanog.  but i thought we duplicated the nanog
experiment at the ietf, testing both nat64 and pure 6.  and i definitely
remember unhappiness, despite the short duration.

the meeting net is a production tool for folk who could not give a damn
about ipvwhatever.  they just want their mtv.  and they will whine and
waste precious plenary time <g> on the slightest little speedbump they
hit on the way to the candy machine.

operators call these people 'users' or 'customers.'  we try to make
their network experience as seamless as possible.

if, instead, they are to be lab rats in the technical experiment of a
minority of the community, then just have the iesg tell the iaoc to
redefine the function of the network.  there are noccers who probably
can still hack the net to give you decnet or x.25.

randy

---

From: "Townsley.net" <[email-masked]>
Date: Mon, 21 Jul 2014 09:52:20 -0400

Picked up by security in Epic restaurant. 

Apologies for the interruption. 

- Mark

(Thumbtyped)

> On Jul 21, 2014, at 9:05 AM, Randy Bush <[email-masked]> wrote:
>

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 25 Jul 2014 13:50:59 -0400

> Many meetings ago Marc Blanchet tapped me on the shoulder and suggested I try out the IETF-NAT64 network. I did. It took only a couple of minutes of my time to try it out. Most things on my iPhone…

- I was not paying attention to this mailing list and someone recently told me about your message.
- thanks for your nice message, but just want to say that this "nat64 experiment" over many IETFs has been a teamwork, and I was just the "communications vehicule". so credits should go to the team.

Regards, Marc.