Subject: IPv4 outage at next IETF in Chicago

From: Franck Martin <[email-masked]>
Date: Tue, 24 Jan 2017 17:11:25 -0600 (CST)

I think it is time to move to the next level of IPv6 deployment. 

Ideally the IETF WiFi network should now only provide the following 2 networks: 
1)IPv6-only 
2)IPv6-only with NAT64 

The later should be the default network. 

However you would say, well some stuff will break, some non technical people will use the IETF network and may have a bad experience, etc... 

So to be conservative but at the same time futurist and like it was done a few years back, why not create again an IPv4 outage of a few hours where the above 2 networks would be the only networks available? 

Depending on results, this outage could be expanded to a full day at the following meeting, until the IPv4 network is totally removed from the WiFi?

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 24 Jan 2017 15:23:34 -0800

On 24 January 2017 at 15:11, Franck Martin <[email-masked]> wrote:

>
> So to be conservative but at the same time futurist and like it was done a
> few years back, why not create again an IPv4 outage of a few hours where
> the above 2 networks would be the only networks available?
>
> Depending on results, this outage could be expanded to a full day at the
> following meeting, until the IPv4 network is totally removed from the WiFi?
>
> If you wish to test that your networks are reachable from a v6-only
environment, there is already a v6-only network you can use to test that.
Many of us require access to the entire Internet to do our jobs, however.

---

From: Franck Martin <[email-masked]>
Date: Tue, 24 Jan 2017 17:34:57 -0600 (CST)

> From: "Matthew Pounsett" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: "IETF" <[email-masked]>
> Sent: Tuesday, January 24, 2017 3:23:34 PM
> Subject: Re: IPv4 outage at next IETF in Chicago

> On 24 January 2017 at 15:11, Franck Martin < [email-masked] > wrote:

>> So to be conservative but at the same time futurist and like it was done a few
>> years back, why not create again an IPv4 outage of a few hours where the above
>> 2 networks would be the only networks available?

> If you wish to test that your networks are reachable from a v6-only environment,
> there is already a v6-only network you can use to test that. Many of us require
> access to the entire Internet to do our jobs, however.

NAT64 allows you to reach the entire IPv4 network, so you should be able to continue to do your job. NAT64 is already deployed on many mobiles in the US. 

Why moving from dual stack IPv4/IPv6 to IPv6 with NAT64? 
It ensures that all the OS and client applications can work in an IPv6 only environment while still be able to reach legacy systems (aka IPv4).

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 24 Jan 2017 17:41:39 -0600

NAT64 doesn’t work for ALL the apps, they may use older API/socks, literal IPv4 addresses, etc.

464XLAT does it, this is what is deployed at the cellular networks in US and many other countries.

Saludos,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Franck Martin <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 24 de enero de 2017, 17:34
Para: Matthew Pounsett <[email-masked]>
CC: IETF <[email-masked]>
Asunto: Re: IPv4 outage at next IETF in Chicago

    ________________________________________

    

    

    If you wish to test that your networks are reachable from a v6-only environment, there is already a v6-only network you can use to test that.  Many of us require access to the entire Internet to do our jobs, however.

    

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 24 Jan 2017 17:41:27 -0600

That’s why I already suggested a way that allow both, dual stack in the IETF LANs, and IPv6 only in the “access” (the link of the router to the LANs).

We can do this with 464XLAT, which has been tried massively in many cellular and residential customer networks.

This is a “more realistic” scenario about what each of us can find in their home networks in months/years from now. Many network and home networks will keep dual-stack, with private IPv4, but global IPv6, because many devices at home are and will be, IPv4 only for some time. You will not replace the IPv4-only devices immediately, right?

If anything fails, we need to know it.

Regards,
Jordi

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Jan 2017 10:56:25 +1100

In message <[email-masked]>,
> I think it is time to move to the next level of IPv6 deployment. 

There are several "next level" alternatives when moving on from dual
stack native IPv4 + native IPv6.

There is:
(1) native IPv6 + RFC 1918 (single NAT)
(2) native IPv6 + RFC 6598 + RFC 1918 (double NAT)
(3) dual stack lite (network)
(4) dual stack lite (host mode)
(5) MAP-*
(6) 464XLAT + RFC 1918
(7) DNS64/NAT64

Now if we want to simulate a IPv6 only access network then the choices
above drop.

> Ideally the IETF WiFi network should now only provide the following 2 network

Somehow the IETF has been brain washed into thinking than DNS64/NAT64
is actually the best solution.  It really is a total piece if garbage
and should be made historic.  It breaks DNSSEC.  It requires that
DNS recursive server accept answers from broken authoritative
servers.  It doesn't prevent PMTU issues.  It doesn't actually have
the reported property that you can tell when you can turn it off.
It makes the network less robust as you cut off IPv4 fallback if
the IPv6 path / servers are broken when both are offered.
 
> The later should be the default network. 

Something other than native IPv4 + native IPv6 should be the default
network.  DNS64/NAT64 is really the worst choice that could be made.
 
> However you would say, well some stuff will break, some non technical people 
> will use the IETF network and may have a bad experience, etc... 
> 
> few years back, why not create again an IPv4 outage of a few hours where the
> above 2 networks would be the only networks available? 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jan 2017 13:33:22 +1300

> So to be conservative but at the same time futurist and like it was done a few years back, why not create again an IPv4 outage of a few hours where the above 2 networks would be the only networks a…

That would be a good way of damaging IETF productivity for a few hours.

And for what? Moving away from the mainstream coexistence mechanism (dual stack),
to a mechanism known to be intrinsically defective (NAT). I don't see the point.

IPv6-only is a *very* long term goal for campus/enterprise networks, which the IETF
network resembles. Our realistic goal today is for enterprise networks to achieve
dual-stack coexistence, and most enterprise network are nowhere near that point yet.

There is no point in leading from so far out in front that nobody else can
see you.

   Brian

---

From: Jared Mauch <[email-masked]>
Date: Tue, 24 Jan 2017 18:53:05 -0600

This experiment would be best done in your home or office environment. 

I have had the described issue occur in real life at home, things went on mostly fine. 

Replicating what carriers like T Mobile USA and EE in the U.K. have done or are in the process of doing will not help folks understand the issues of v4 or v6. 

There is a whole host of minor issues that should be fixed in v6 that won't be addressed by this proposed experiment. With things like DNSSEC and such out there your router can't lie when you type router.login to your browser for example. People are still using the same old Linux or VxWorks with bugs and don't do AF_INET6 or a higher layer API. 

Much of the trouble comes from the consumer electronics space and lack of implementing of known best practices. 

Jared Mauch

> On Jan 24, 2017, at 5:11 PM, Franck Martin <[email-masked]> wrote:
>

---

From: Franck Martin <[email-masked]>
Date: Tue, 24 Jan 2017 19:05:37 -0600 (CST)

----- Original Message -----
> From: "Brian E Carpenter" <[email-masked]>
> To: "Franck Martin" <[email-masked]>, "IETF" <[email-masked]>
> Sent: Tuesday, January 24, 2017 4:33:22 PM

> That would be a good way of damaging IETF productivity for a few hours.

Do you have evidence of applications not running in a NAT64 environment? I'm interested to know them.

> to a mechanism known to be intrinsically defective (NAT). I don't see the point.

I fail to see how NAT is intrinsically defective, since it is used successfully by everyone...

Nevertheless, the goal here is to get the Internet designers (IETF) to have operational experience on what needs to be fixed.

When the IPv4 outage happened a few years back, it gave a serious impetus in getting IPv6 totally mainstream on many platforms.

IAB encourages IPv6: https://www.iab.org/2016/11/07/iab-statement-on-ipv6/

However going IPv6-only can only be done in walled gardens. There still will be many environments with IPv4 only. A solution here is to move networks to NAT64, so you only need to support IPv4 at the edges...

Yes creating an outage for the sake of an outage is pointless, experience on what works and not work needs to be recorded.

May be the first step instead of doing an outage is to have as default a NAT64 network at IETF meetings and a dual stack network for the people that experience issues.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jan 2017 14:21:23 +1300

Franck, I try not to be religious about NAT, and I use NAT44 every day
like most people. Also like most people, I experience occasional
unexplained failures of web-based transactions. Whether they are due
to a NAT garbage-collect or a load-balancer failure, I don't know,
of course. But actually I am not deeply concerned about NAT64, although
any failures that it generates would be very hard to identify. I am
more concerned about IETF participants whose devices are not set up
as dual stack nodes at all. They would be completely blocked. Yes,
I know, such people should not exist, should be deeply ashamed, etc.
But I don't see why we would cut them off to prove a point.

Regards
   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Jan 2017 12:46:08 +1100

In message <[email-masked]>,
 Franck Martin writes:
> >> However you would say, well some stuff will break, some non technical
> >> people will use the IETF network and may have a bad experience, etc...
> >> 
> >> So to be conservative but at the same time futurist and like it was
> >> done a few years back, why not create again an IPv4 outage of a few
> >> hours where the above 2 networks would be the only networks available?
> > 

Anything that really wants to know is AAAA records exist or not.
You don't run NAT64 w/o DNS64 and that munges with DNS answers.
Lots of what I do would break because of that.  I need to know the
truth, not the lies from DNS64.  And yes I have written DNS64 code.

> successfully by everyone...

No one successfully uses NAT.  They just put up with its limitations.
There is a big difference.  That said there will always be limitations
delivering IPv4 going into the future.

> Nevertheless, the goal here is to get the Internet designers (IETF) to
> have operational experience on what needs to be fixed.

Step 1.  Stop saying to use NAT64.  There are other ways to provide
IPv4 as as a service with IPv6 only all the way to the node.

> When the IPv4 outage happened a few years back, it gave a serious impetus
> in getting IPv6 totally mainstream on many platforms.
> 
> However going IPv6-only can only be done in walled gardens. There still will 
> be many environments with IPv4 only. A solution here is to move networks to
> NAT64, so you only need to support IPv4 at the edges...

No.  The goal is IPv6-only access networks with IPv4 as service,
then IPv6-only within the home / enterprise with IPv4 as a service.
Note this doesn't specify a solution.

> Yes creating an outage for the sake of an outage is pointless, experience on 
> what works and not work needs to be recorded.
> 
> May be the first step instead of doing an outage is to have as default
> a NAT6 4 network at IETF meetings and a dual stack network for the people
> that experience issues.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 24 Jan 2017 19:50:37 -0600

Sometimes, is not IETF people fault, I will say most of the time.

We all are mandated, by corporate policy to use apps (that we don’t develop), which may still use IPv4 literals, older APIs, etc. Those will fail. The same that will fail if we live in a world with IPv6 only access networks for our offices or homes and don’t have dual-stack in our LAN with something to sort out the problems of those apps.

You want an example, just try skype with NAT64 … (unless they sorted it out already).

Some more (I found a table some time ago googling, but not sure where is it): Google Talk, Google+, Last.fm, Netflix, ooVoo, Pirates of the Caribean, Spofity, Tango, Texas Poker, …

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Brian E Carpenter <[email-masked]>
Organización: University of Auckland
Responder a: <[email-masked]>
Fecha: martes, 24 de enero de 2017, 19:21
Para: Franck Martin <[email-masked]>
CC: IETF <[email-masked]>
Asunto: Re: IPv4 outage at next IETF in Chicago

    Regards
       Brian

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 24 Jan 2017 16:32:04 -1000

On Tuesday, January 24, 2017 1:56 PM, Mark Andrews wrote:
> In message
<[email-masked]>,
 Franck Martin writes:
> ...

Language apart, there is a serious question here. Did the IETF produce the
right standards for IPv6 only networks? Is NAT64/DNS64 useful or harmful?
What else are we missing? It seems that the IETF should try to answer that
sooner rather than later. The IETF culture, besides the flowery language,
encourages practical engineering and experimentation over speculation. So,
yes, maybe we should do some practical experimentation, just like Franck
Martin is proposing.

Some of that experimentation is of course going on outside the IETF, as
reported is this APNIC blog entry
https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/. The blog explains
that Microsoft IT wants to move their network to IPv6 only. They have so
many devices that using RFC 1918 addresses requires multiple layers of NAT,
and that is really painful to manage. Moving to IPv6 only would reduce the
management costs, but of course they have to proceed cautiously. One of the
starting points is to deploy IPv6 only in the "guest" network, the Wi-Fi
networks used by visitors. This is interesting, because the usage profile of
this guest network is very similar to that of the IETF network: visitors
using the Internet and connecting back to a variety of companies.

As you might expect, they did find issues. Some routers lacked support for
RDNSS (RFC6106), and that prevented access by Android devices. The
deployment of Azure-AD requires dynamic ACLs (name-based), and these were
not supported with IPv6 by some vendors. They found a DHCPv6 bug in Windows
10, which affected both stateful and stateless schemes, but was masked in
dual stack deployments. All of these issues are being fixed. On the other
hand, they did not find any particular issue with NAT64/DNS64, maybe because
few of their visitors actually require DNSSEC.

Could we find similar issues with the current IETF network setup? Possibly,
but I expect that the bugs will happen in corner cases, such as old OS
releases or specific business applications. We will only find these bugs if
a large variety of people actually try the IPv6 only network, and complain
when stuff does not work. We need to encourage people to actually try the
IPv6 only network. Disconnecting IPv4 is one radical way to do that. It
certainly has its merits.

-- Christian Huitema

---

From: Jeffrey Eric Altman <[email-masked]>
Date: Tue, 24 Jan 2017 21:48:11 -0500

> On Jan 24, 2017, at 8:05 PM, Franck Martin <[email-masked]> wrote:
> 
> 

AFS

The afs location service returns explicit IPv4 addresses for volume locations not names to be looked up via DNS.

Jeffrey Altman

---

From: Michel Py <[email-masked]>
Date: Wed, 25 Jan 2017 03:11:08 +0000

> Christian Huitema wrote :
> The blog explains that Microsoft IT wants to move their network to IPv6 only.

And I'm sure there is another quite helpful blog that explains why Microsoft IT wants to move to a Windows 10 only environment too.

Michel.

---

From: Franck Martin <[email-masked]>
Date: Tue, 24 Jan 2017 21:24:31 -0600 (CST)

Brian,

This is hardly to prove a point.

It is to have an operational experience so that stuff gets fixed and standards get written to fix stuff.

An IPv4 outage is radical, granted, may be it should be done during hackday on the weekend before IETF. May be it should not be done at all and instead the default network SSID:IETF to be NAT64, with an SSID:IETF-IPv4-only.

May be NAT64 is not the right one, may be it is XLAT464? (NAT64/DNS64 does not require much client participation, XLAT464 does).

May be it is way too short to have it in Chicago? Likely.

May be it should be better planned. Certainly.

We need a transition to IPv6-only, this go via dual stack, sure, but do we have to wait for the whole world to be IPv6 before we can deprecate IPv4? No, we need something that allows to have IPv6-only networks (enterprise, guest, customers,...) capable of talking to the legacy Internet. We also realize that the bottom line is: "dual stack=dual costs" and "dual stack=dual security issues". As the world progress, the need for NAT64 will go away...

So, this is a very interesting discussion, as long we move towards some solution(s).

What do you propose?

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Franck Martin" <[email-masked]>
Cc: "IETF" <[email-masked]>
Sent: Tuesday, January 24, 2017 5:21:23 PM
Subject: Re: IPv4 outage at next IETF in Chicago

Regards
   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Jan 2017 14:27:02 +1100

In message <[email-masked]
> >, Michel Py writes:
> And I'm sure there is another quite helpful blog that explains why
> Microsoft IT wants to move to a Windows 10 only environment too.
>
> Michel.

But Microsoft aren't the only ones that are looking to deploy
IPv6-only due to not having enough IPv4 addresses internally.  There
is also Google, Facebook ...

The IETF has produced multiple solutions that provide IPv4 as a
service with IPv6-only to the node.  All of them require IPv6 nodes
and/or applications to be updated to be generally useful.

NAT64/DNS64 requires applications which deal with IPv4 literals to
be updated.

Dual-Stack-Lite node mode requires a tunnel interface be configured
the destination address of which is advertised in a DHCPv6 option.
For those that don't like DHCPv6 we could add a RA option.

One just breaks more things.  I'll let you guess which.

Mark

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 24 Jan 2017 21:31:20 -0600

Frank,

What I’m proposing will not involve installing the “client” part in the devices connecting to the IETF network.

The idea is the following:

Upstream provider – IETF router – NAT64/DNS64 – CLAT (can be a virtual machine) – IETF default SSID
                                                 |------------------------------ other IETF SSIDs

So I’m saying the IETF default SSID will behave as a “residential” LAN of the CLAT enabled “CPE”.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Franck Martin <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 24 de enero de 2017, 21:24
Para: Brian E Carpenter <[email-masked]>
CC: IETF <[email-masked]>
Asunto: Re: IPv4 outage at next IETF in Chicago

    Brian,

    

    

    
    What do you propose?
    
    ----- Original Message -----
    From: "Brian E Carpenter" <[email-masked]>
    To: "Franck Martin" <[email-masked]>
    Cc: "IETF" <[email-masked]>
    Sent: Tuesday, January 24, 2017 5:21:23 PM
    Subject: Re: IPv4 outage at next IETF in Chicago

    Regards
       Brian

---

From: Franck Martin <[email-masked]>
Date: Tue, 24 Jan 2017 21:32:52 -0600 (CST)

----- Original Message -----
> From: "Jeffrey Eric Altman" <[email-masked]>
> Cc: "Brian E Carpenter" <[email-masked]>, "IETF" <[email-masked]>
> Sent: Tuesday, January 24, 2017 6:48:11 PM

> not names to be looked up via DNS.
Very Interesting, Thanks.

1) is AFS run on IETF network?
2) if AFS is external, would NAT64 not take care of the translation? NAT44 does packet inspection for that kind of stuff for like FTP and SIP.
3) Why IPv6 support is on the wish list? https://www.openafs.org/roadmap.html

---

From: Michel Py <[email-masked]>
Date: Wed, 25 Jan 2017 03:49:05 +0000

> Mark Andrews wrote :
> But Microsoft aren't the only ones that are looking to deploy IPv6-only due to not
> having enough IPv4 addresses internally.  There is also Google, Facebook ...

Your record has a groove. Been reading this for 15 years.

> The IETF has produced multiple solutions that provide IPv4 as a service with IPv6-only to the node. 
> All of them require IPv6 nodes and/or applications to be updated to be generally useful.

I run an IPv4-only network.

I like Brian Carpenter's pragmatism. The IPv6-only dream only exists in the IETF ivory tower.

Michel.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Jan 2017 15:15:34 +1100

In message <[email-masked]
>, Michel Py writes:
> > Mark Andrews wrote :
> > But Microsoft aren't the only ones that are looking to deploy IPv6-only d=
> ue to not
> > having enough IPv4 addresses internally.  There is also Google, Facebook =
> ...
> 
> > The IETF has produced multiple solutions that provide IPv4 as a service w=
> ith IPv6-only to the node.=20
> > All of them require IPv6 nodes and/or applications to be updated to be ge=
> nerally useful.
> 

And there are IPv4 as a service access solutions for that network.

> I like Brian Carpenter's pragmatism. The IPv6-only dream only exists in

The Mac I'm using is running in IPv6 only mode at the moment (just
turned IPv6 off in network managment panel).  I can get to the
corporate mail servers.  I can get to all the corporate web sites.
Jabber works from it.  I can get to the git repositories.

If my ISP would give me IPv6 I could get away without IPv4 for
almost all my work activities.

Now if Google would give their DNS servers AAAA addresses I could
get to the rest of their servers.  Come on Google your 99.9% of the
way there.

Facebook is reachable.

IPv6 only is definitely achievable.

Mark

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jan 2017 08:53:44 +0000

On 24/01/2017 23:11, Franck Martin wrote:
> Depending on results, this outage could be expanded to a full day at 
> the following meeting, until the IPv4 network is totally removed from 
> the WiFi?

How about those that designed IPv6 and their ADs subject themselves to 
this regime and report to the rest of us how they got on?

- Stewart

---

From: Marco Davids <[email-masked]>
Date: Wed, 25 Jan 2017 13:20:57 +0100

> get to the rest of their servers.  Come on Google your 99.9% of the

Yes, come on Google!

https://en.internet.nl/site/www.google.com/57047/

-- 
Marco

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Jan 2017 09:05:45 -0500

+1
And add anyone who has been strongly advocating this, and other
"if you are not running IPv6 exclusively, we should punish you"
strategies, to that list.

    john

--On Wednesday, January 25, 2017 08:53 +0000 Stewart Bryant
<[email-masked]> wrote:

>> Depending on results, this outage could be expanded to a full
>> day at  the following meeting, until the IPv4 network is
>> totally removed from  the WiFi?
> 
> How about those that designed IPv6 and their ADs subject
> themselves to this regime and report to the rest of us how
> they got on?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 25 Jan 2017 06:34:37 -0800

+10

Coercion is becoming an essential part of the US's new political 
paradigm, but the IETF is an international organization and needn't 
embrace it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Jan 2017 14:49:17 -0000

Yes, it wasn't clear to me whether this was experimentation, punishment,
torture, or hair-shirt.

If the purpose is experimentation, I urge you to experiment with willing
participants. Entice, don't coerce.

It could be very valuable to set up various v6-only networks with different
tools and methodologies, and invite us all to try them out. This would be best
done with some feedback mechanisms (a simple form showing, OS and version,
applications, experiences?) and might show that at future IETFs we could run
specific networks.

Adrian

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 25 Jan 2017 07:44:51 -0800

On 25 Jan 2017, at 6:49, Adrian Farrel wrote:

> tools and methodologies, and invite us all to try them out.

At IETF meetings over the past few years, I have seen various SSIDs that 
indicate v6-only and v6-with-some-protocol, so I think we already do 
that.

> This would be best

At IETF meetings over the past few years, I have not seen reports to the 
IETF community about these networks.

Franck: Organizing such feedback mechanisms would be *very* helpful to 
those of us who might support more emphasis on those technologies in the 
nearer future. I wouldn't be so resistant to using such a network if I 
knew what to look for.

Others: if you want to see this experiment succeed, maybe gamify it a 
bit and offer small prizes at the Bits-and-Bytes for the most successful 
experience on these nets and the most humo(u)rous failures found.

--Paul Hoffman

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 25 Jan 2017 10:28:02 -0800

On 24 January 2017 at 18:32, Christian Huitema <[email-masked]> wrote:

> Experimentation is good.  But don't do it on the main IETF network, as
Franck is suggesting.  That's what we have the v6-only SSID and others are
for.

IETF participants have operational responsibilities.  Any of these "let's
run an experiment on the main access network!" ideas that have a potential
to break anyone's applications are bad ideas.  Such experiments need to be
run on experimental networks.

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 Jan 2017 10:59:29 -0800

> It could be very valuable to set up various v6-only networks with
> different tools and methodologies, and invite us all to try them out.

nat64 and v6only ssids have been provided for a long time.  you are
strongly encouraged to try them and report.

randy

---

From: Franck Martin <[email-masked]>
Date: Wed, 25 Jan 2017 13:06:58 -0600 (CST)

Besides all the passive aggressiveness of some responses, I like what Paul Hoffman proposed and I would be game to help run this... However I don't have control on the IETF network. How would I go about requesting an SSID for IPv6-only with NAT64/DNS64 is setup? 

I would take care of running a jabber channel, encourage people to switch and test, create some forms to collect experience and report back. 

I would even be willing to offer a real vintage LinkedIn IPv6 polo shirt as prize... ;)

---

From: Michal Krsek <[email-masked]>
Date: Wed, 25 Jan 2017 20:14:02 +0100

Hi Franck,

> Besides all the passive aggressiveness of some responses, I like what 
> Paul Hoffman proposed and I would be game to help run this... However 
> I don't have control on the IETF network. How would I go about 
> requesting an SSID for IPv6-only with NAT64/DNS64 is setup?
>
> I would take care of running a jabber channel, encourage people to 
> switch and test, create some forms to collect experience and report back.
>

as Randy wrote already, various SSIDs with various v6 setups are 
deployed regularly for years.

                 Michal

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Jan 2017 08:48:29 +1300

> this regime and report to the rest of us how they got on?

I've helped a bit, and I exercise the model suggested by RFC1671
most days. It works. I see no reason to subject myself to an artificial
restriction.

   Brian

---

From: joel jaeggli <[email-masked]>
Date: Wed, 25 Jan 2017 11:58:54 -0800

> requesting an SSID for IPv6-only with NAT64/DNS64 is setup?

from the ietf97 all network information and roughly the previous 20 or
so ietf meetings with variations since which ssids provide what and the
names of the primary networks have changed over time:

...

Here’s a quick summary of the network layout: || SSID || Description ||
Encrypted || Frequencies || IP Versions || || ietf || Our default
network || yes || 5Ghz only || v4 and v6 || || ietf-legacy || For legacy
and unencrypted use || no || 2.4 and 5Ghz || v4 and v6 || ||
ietf-2.4ONLY || An encrypted network for 2.4Ghz users || yes || 2.4Ghz
only || v4 and v6 || || ietf-v6ONLY || For users wanting pure IPv6 ||
yes || 5Ghz only || v6 only || || ietf-nat64 || IPv6 stack with NAT64 ||
yes || 5Ghz only || v6 with NAT64 & DNS64 || || eduroam || educational
users || yes || 2.4 and 5Ghz || v4 and v6 || All networks marked as
encrypted will offer layer 2 security. This is done using WPA2
enterprise with 802.1X (PEAP or TTLS) authentication and AES encryption.
As usual, we are all using the same credentials (user “ietf”, password
“ietf”), yet each user will get unique session encryption keys. Our
802.1x authentication servers use a certificate that you can install by
going to this page: [https://802.1x-config.org/?idp=137&profile=60] or
alternatively, check them yourself here:
[https://tickets.meeting.ietf.org/wiki/CertCheck] ...

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Jan 2017 07:48:24 +1100

In message <[email-masked]>
, Matthew Pounsett writes:
> --94eb2c1245889d92230546ef644f
> Content-Type: text/plain; charset=UTF-8
> 

There is benefit in making the ssid "ietf" not native IPv4 and
native IPv6 and for us to be eating our own dog food on it.  Tell
people that it isn't DS native.  Don't tell them which IPv4 as a
service technology they are using until the plenary.  Most of the
IPv4 as a service technologies shouldn't impact anyone when done
at the network level as they just present as double NAT IPv4 layer
to the device with a resticted IPv4 path MTU.

When you get to IPv4 as a service node level it becomes more
interesting.  This is where DNS64/NAT64 and DS-lite (node mode)
fit.

Have "ietf-native" ssid (dual stack native IPv4/IPv6) as a fallback
network.  We already have various fallback ssids.  It isn't hard
to switch ssids.

Mark

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jan 2017 18:48:53 -0500

What I would much prefer is that we fix the horrible UI problem for WiFi.

Captive portals for logging into WiFi are a 1000% worse suck than NAT. They
don't just change end to end consistency of IP addresses (which I don't
care about), they smash up the TLS trust model which is something we should
care about a very great deal.

Getting people to accept T&C is a logical requirement prior to joining any
network. For IETF, T&C should include Note Well.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Jan 2017 19:14:21 -0500

,
- - -

On Wed, Jan 25, 2017 at 2:14 PM, Michal Krsek <[email-masked]> wrote:
> Hi Franck,
>
>
> Besides all the passive aggressiveness of some responses, I like what Paul
> Hoffman proposed and I would be game to help run this... However I don't
> have control on the IETF network. How would I go about requesting an SSID
> for IPv6-only with NAT64/DNS64 is setup?
>
> I would take care of running a jabber channel, encourage people to switch
> and test, create some forms to collect experience and report back.
>
> as Randy wrote already, various SSIDs with various v6 setups are deployed
> regularly for years.

Yup.
We've also had *very* similar discussions a number of times. I'd been
trying to stay out of this tread because rant, but I'd really
encourage people to read some of the archives and similar.

An IPv6-only SSID already exists -- it's even currently called
"ietf-v6ONLY" (For users wanting pure IPv6 ). There is also
"ietf-nat64" (IPv6 stack with NAT64). This information is regularly
communicated -- for example:
Jim's email "[97all] IETF 97 Network Information – Seoul, South Korea"
the IETF NOC reports - e.g: for IETF97 -
https://www.ietf.org/proceedings/97/slides/slides-97-ietf-sessa-noc-report-00.pdf
, Slide 6 shows associations per SSID. 3 on ietf-v6ONLY and 19 on
ietf-nat64.
As someone who's been involved in the NOC, I'm slightly irritated by
the "You should really supply X, everyone wants it, how do I get this
done?!" tone when it's been available (and not very widely used) for
many years, and that a few seconds looking would have shown this.

There has also been lots of previous discussion on this, for example:
IETF 97 Plenary -
https://www.ietf.org/proceedings/97/minutes/minutes-97-ietf-00.html

7. IAB Open Mic Session

"John Brzozowski referred to the IAB statement on IPv6, and suggested
making the primary IETF SSID v6-only, perhaps with NAT64. One thing
Comcast is working on is v6-only for end-user devices, supporting
NAT64 and other implementations. They are seeing an increase in IPv6
traffic and a decrease in IPv4 traffic. John Brzozowski said that it
makes sense for the IETF community's primary SSID to outline a path
forward for IPv6-only.

Jari Arkko said that he would like to see some of this, and thinks
that an incremental approach is what we need. Lee Howard asked how he
would like the IAB to write tht plan. Jari Arkko replied that an
Internet-Draft would work.

* Mark Townsley noted that the IETF turned off IPv4 for an hour at
IETF 71 in Philadelphia back in 2008. There are other technical
conferences of size that are going this already. Mark Townsley suggest
that we move to IPv6-only, and turn off NAT64 during the plenary as an
experiment.

* David Schinazi expressed support John Brzozowski's initiative
towards IPv6-only."
------------

IETF71 IPv4 Outage  - https://wiki.tools.isoc.org/IETF71_IPv4_Outage

IETF network incremental plan -- 16 Nov 2016 -
https://www.ietf.org/mail-archive/web/ietf/current/msg99866.html

[v6ops] IPv6-only wifi during IETF meetings? - expect higher energy
consumption -- 16 Nov 2016 -
https://www.ietf.org/mail-archive/web/v6ops/current/msg25211.html

Moving to having the primary SSID be v6 only, or nat64 or whatever is
definitely doable, but it should really be approached in a reasoned
manner, looking at things like how the network currently works,
responses from the surveys, etc.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Lee Howard <[email-masked]>
Date: Thu, 26 Jan 2017 11:12:38 -0500

>"ietf-v6ONLY" (For users wanting pure IPv6 ).

I spend as much time as I can on that one, and have sent email to the NOC
about things that break. For me, Jabber was a key one that kept me from
staying there; I believe Google was unable to authenticate my Jabber
account over IPv6.
The unavailability of Github is another recurring problem, when so many
WGs store stuff there.

>There is also
>"ietf-nat64" (IPv6 stack with NAT64).

So I end up spending a lot of time on this one. Mostly works.

Question for you NOC folks: when I report a problem, how much information
do you need?
For instance, I can say, ³Jabber failed.²
Or I can say, ³Jabber failed, here¹s my account.²
Or I can say, ³Here¹s a packet capture of trying to log into Jabber.²
But I don¹t want to provide more data than is useful.

Also, I don¹t know of any reporting on tickets like that. That kind of
reporting would help us understand what still breaks on IPv6-only or
NAT64, and therefore how much pain it would be to make one of those
configurations be the default SSID. It would also help us focus pressure
on the apps and tools that break in such scenarios; if my Jabber problem
turns out to be authentication at Google, I could find somebody there who
might be able to help. Or if it¹s my client, I might be able to find (or
fund) the needed update.

Would you folks give us some guidance on how to report issues, and provide
some reports, so we can have metrics telling us when we can reasonably
make changes?

>This information is regularly
>Jim's email "[97all] IETF 97 Network Information  Seoul, South Korea"

Thanks for that pointer; these reports often go by too fast.
I find it fascinating that ietf-legacy is significantly more popular than
ietf. Why is that?

>many years, and that a few seconds looking would have shown this.

Fair enough, and I understand the primary requirement for the IETF network
is to let people get their work done. So I¹m trying to figure out how to
list stuff that wouldn¹t work, so we can clear the way, so we don¹t
interfere with work.

Somebody earlier in the thread said something like, ³Let the IPv6 zealots
use IPv6.² We are. And we¹ve resolved what we can, and reported the rest.

>Internet-Draft would work.

I think his actual words were more like, ³THat¹s one way to do it, but it
doesn¹t even have to be a draft.²

[more links elided, but thanks for them]
Š

Lee

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Jan 2017 09:02:48 -0800

> But I don¹t want to provide more data than is useful.

maximize data to allow to reproduce, but minimize PII.  and if it is a
well-known problem, e.g. skype, just X on platform Y does not work over
ssid Z on date D.

> Also, I don¹t know of any reporting on tickets like that.

i think it would be nice if the ipv6 folk put in a little work here.
maybe a wiki or whetever.  please remember the noc folk on whom you are
leaning are also unpaid volunteers.  though we can put up a service
(wiki or whatever) for you to use.

> That kind of reporting would help us understand what still breaks on
> IPv6-only or NAT64, and therefore how much pain it would be to make
> one of those configurations be the default SSID.

when a significant number of folk have actually tested, reported, and
problems have been fixed sufficiently that the masses can get their MTV,
let's talk mucking with the default network.

> Would you folks give us some guidance on how to report issues, and
> provide some reports, so we can have metrics telling us when we can
> reasonably make changes?

we have a ticket system and there is a way for you to generate tickets.
but, imiho, tickets are not a great way to document the space.  when you
have a particular issue and are working on getting it fixed, tickets are
great.  but they's an unintelligible mess for tryingt to make a matrix
of whether X works on network flavor Y with platform Z.

> I understand the primary requirement for the IETF network is to let
> people get their work done. So I¹m trying to figure out how to list
> stuff that wouldn't work, so we can clear the way, so we don't
> interfere with work.

solid plan

randy

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 Jan 2017 12:08:14 -0500

Lee,

This strongly suggests that it would be a good idea for the NOC
to have a web-based reporting form that specifically asks for
(or, when possible, automagically fills in) whatever information
is needed to cause a ticket to make sense and be useful.  I'd
hate to see such a thing replace the email options -- if nothing
else, if one is trying to work around a problem but still report
it, it may be faster to get an email message out and that speed
may make the difference between a useful "something is wrong'
heads-up report and silence -- but the odds of many of us
spontaneously remembering a list of things that should be
included in a report are not very high.

best,
   john

--On Thursday, January 26, 2017 11:12 -0500 Lee Howard
<[email-masked]> wrote:

> I spend as much time as I can on that one, and have sent email
> to the NOC about things that break. For me, Jabber was a key
> one that kept me from staying there; I believe Google was
> unable to authenticate my Jabber account over IPv6.
> The unavailability of Github is another recurring problem,
> when so many WGs store stuff there.
> 
>> There is also
> Question for you NOC folks: when I report a problem, how much
> information do you need?
> Or I can say, ³Here¹s a packet capture of trying to log into
> Jabber.² But I don¹t want to provide more data than is
> useful.
> 
> That kind of reporting would help us understand what still
> breaks on IPv6-only or NAT64, and therefore how much pain it
> would be to make one of those configurations be the default
> SSID. It would also help us focus pressure on the apps and
> tools that break in such scenarios; if my Jabber problem turns
> out to be authentication at Google, I could find somebody
> there who might be able to help. Or if it¹s my client, I
> might be able to find (or fund) the needed update.
> 
> Would you folks give us some guidance on how to report issues,
> and provide some reports, so we can have metrics telling us
> when we can reasonably make changes?
> 
> 
>> Jim's email "[97all] IETF 97 Network Information  Seoul,
>> South Korea" the IETF NOC reports - e.g: for IETF97 -
>> https://www.ietf.org/proceedings/97/slides/slides-97-ietf-ses
>> sa-noc-report -00.pdf
>> , Slide 6 shows associations per SSID. 3 on ietf-v6ONLY and
>> 19 on ietf-nat64.
> 
> I find it fascinating that ietf-legacy is significantly more
> popular than ietf. Why is that?
> 
>> As someone who's been involved in the NOC, I'm slightly
>> irritated by the "You should really supply X, everyone wants
>> it, how do I get this done?!" tone when it's been available
>> (and not very widely used) for many years, and that a few
>> seconds looking would have shown this.
> 
> Fair enough, and I understand the primary requirement for the
> IETF network is to let people get their work done. So I¹m
> trying to figure out how to list stuff that wouldn¹t work, so
> we can clear the way, so we don¹t interfere with work.
>...

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Jan 2017 09:08:53 -0800

> well-known problem, e.g. skype, just X on platform Y does not work
> over ssid Z on date D.

how about a running i-d in interop report style?  seems to me that would
be kinda the normal responsibility of folk developing and advocating use
of these mechanisms.

> we have a ticket system and there is a way for you to generate

i think jim puts destructions on how to use it with every meeting's
network announcement.  if not, i am sure he will now :)

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Jan 2017 11:14:21 -0800

> is needed to cause a ticket to make sense and be useful.

will leave as exercise for student finding the network announcement from
a recent meeting and following it to the existing ticketing system
before micro-managing it.

randy

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 Jan 2017 14:19:27 -0500

Noted and agreed.
   john

--On Thursday, January 26, 2017 11:14 -0800 Randy Bush
<[email-masked]> wrote:

>> This strongly suggests that it would be a good idea for the
>> NOC to have a web-based reporting form that specifically asks
>> for (or, when possible, automagically fills in) whatever
>> information is needed to cause a ticket to make sense and be
>> useful.
> 
> will leave as exercise for student finding the network
> announcement from a recent meeting and following it to the
> existing ticketing system before micro-managing it.