Subject: IETF network incremental plan

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 16 Nov 2016 19:26:44 +0900

Answering what Jari asked at the beginning of the session and also some other comments on the mike, I think the plan must be something like:

1) At this point make sure to identify what apps still not work with IPv6-only in the LAN. How we do that, easy. Use 464XLAT or MAP, or even better, try one at one IETF meeting, the other one at the following meeting. Our network first hop router, must behave as a dual-stack device in the LAN (IETF default SSID network), IPv6-only to the access.
2) Once we have identified by means of a scrip in that first hop router what apps still need IPv4, talk to the vendors, to tell them about the problem: Look your apps aren’t going to work in the short future.
3) We can keep running this for 3 meetings, for example, 464XLAT, then MAP-T, then MAP-E, one meeting each protocol in the default SSID.
4) After that, decide if is already time to have a REAL IPv6 only as the default SSID, or we need some more meetings with the same test, in case there are still too many apps to be identified. I’m sure we will not discover all the apps, that’s clear, but maybe a good set of what are more relevant at least for this community.
5) In any case, we should always provide a regular dual-stack SSID (not the default one), because people need to work both here in the IETF and his home/office work.
6) It doesn’t make sense to have just a NAT64 SSID. This clearly only is useful to break apps. We get the same result if there is a script at the first hop router that identifies the apps, without breaking it.

Why we need 1), because the actual reality is that still many apps need IPv4 and will not work in an IPv6-only network.

The reality is that even ISPs could deliver IPv6-only access, the idea is to have dual-stack in the LANs, and the IETF is one of those LANs.

Any other alternative should not work at the time being, we like it or not, IPv4 is still there.

Any of you will take the risk to disable IPv4 in your home network? Or even in the corporate network?

I’m sure missing lots of details, but I think the overall plan is there.

I think it has been mention about writing a draft about this, happy to work on that, of course.

Regards,
Jordi

**********************************************
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: Randy Bush <[email-masked]>
Date: Thu, 17 Nov 2016 09:16:43 +0900

last evening i was carrying a question from the noc team but my position
in the mic queue was preempted by more important people.

but essentially, before we make tactical decisions we would like to know
what the purpose and goal of the meeting network is.

  o folk just want to get work done, and the net should bloody well work

  o i want to forward test internet futures: ipv6, auth methods, crypto,
    ...

  o i have my own stuff i want to test (which may need inbound sessions)

  o network?  what network?

in the nat64 case, are we trying to validate the well-known lists of
what does not work over nat64, spotify, many vpns, ...?  if it is
because we think we can modify nat64 to ameliorate the problems, this
would be brilliant.

if we know what the goals are, we should be able to meet them.  so far,
the assumption is that

  o the primary goal of the meeting netowrk is for attendees to get work
    done

  o nats breaking applications and inbound connections would be
    considered as breakage

  o we do want to support occasional experiments, both non-disruptive
    and visible (remember the v6-only plenary?)

  o but basically, i just want my mtv

randy, not speaking for anyone else

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 09:32:36 +0900

At present android apps running on chromebooks do not work over nat64.
  I believe one of our colleagues at Google has filed a bug report on
this, so hopefully it will no longer be an issue in Chicago.

OpenVPN works with nat64, but requires special configuration file
hacking in some cases.

I have no other issues with it.   If it weren't for the fact that my
xmpp app is an Android app, I would be using ietf-nat64 exclusively.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2016 10:01:46 +0900

I very much like the stable plus experimental network setups we currently do. If possible, please keep doing these.

Paul

Sent from my iPhone

> On Nov 17, 2016, at 09:16, Randy Bush <[email-masked]> wrote:
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 17 Nov 2016 10:06:16 +0900

Hi Randy,

In my opinion the primary goal is to have everybody getting the work done, then testing our own protocols. Non-goal is to have individuals own stuff tested.

Also, I’m speaking only about the main Wireless SSID. We can keep other SSID and the terminal room Ethernet ports, pure dual stack as we have today, which allows testing your own stuff and sorting out possible issues in case of “emergency” or major breach of our tests.

NAT64 is not useful because you need to manually write down what works, what not. That’s why I’m suggesting having a first hop router with, for example a modified OpenWRT version of 464XLAT, which logs each use of CLAT and PLAT. This way we could get an automatic list of what are the apps that fail to work with IPv6, which ones work with only PLAT, and which ones need CLAT.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Randy Bush <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 17 de noviembre de 2016, 9:16
Para: Jordi Palet Martinez <[email-masked]>
CC: IETF discussion list <[email-masked]>
Asunto: Re: IETF network incremental plan

    

    
      o network?  what network?

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 10:24:15 +0900

Interestingly, Windows 10 mobile refuses to join the networks that have no v4 (v6only and nat64).  It is interesting because it does use the IPv6 address in ‘ietf’.

But the top consideration is to get work done.

Yoav

Sent from my Windows 10 phone

From: Ted Lemon
Sent: Thursday, November 17, 2016 9:33
To: Randy Bush
Cc: IETF discussion list; Jordi Palet Martinez
Subject: Re: IETF network incremental plan

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2016 14:26:59 +1300

> in the mic queue was preempted by more important people.

I can only wonder.

...
>   o the primary goal of the meeting netowrk is for attendees to get work

Yes. And that's my primary goal everywhere. Which means dual stack. EOM.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Nov 2016 20:33:50 -0500

> in the mic queue was preempted by more important people.

I believe I was the person responsible for queue mamangement where
Randy's priority was not respected.  I have already apologised to him
privately, but I hereby unreservedly apologise for failing to account
correctly for the order at which people got to the mic.  I asked Randy
to post his question to the IAB here, and he told me he would decline.

> what the purpose and goal of the meeting network is.

[&c.]

If that _is_ the question, I observe that the IAB can't answer the
question.  The original question about the v6-only network was asked
of me as to my opinion, so I answered it.  But the IAB doesn't make
decisions about what the IETF network is for at these meeting.  So
while I think the question is important, I don't think the IAB can
answer it, which is what I think I'd have had to tell Randy at the mic
last night.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Thu, 17 Nov 2016 10:34:00 +0900

> Yes. And that's my primary goal everywhere. Which means dual stack. EOM.

I sort of like the idea of making the default IETF SSID IPv6 only, with other SSIDs that support v4/dual stack. It would probably be an eye opening experience for some.

Regards,
-drc
(speaking only for myself)

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 17 Nov 2016 10:39:17 +0900

That’s why at the time being, I’m insisting in looking into the real world:

The real world expects that we have dual stack (private IPv4 + GUA IPv6) in the LANs.

What we need to make sure is that the “access” being IPv6 only, as many ISPs runout of IPv4, is workable by means of a translation in the first hop router (what it will be the CE/CPE in a residential, or SOHO router in an SME, etc.).

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 17 de noviembre de 2016, 10:24
Para: Ted Lemon <[email-masked]>, Randy Bush <[email-masked]>
CC: IETF discussion list <[email-masked]>, Jordi Palet Martinez <[email-masked]>
Asunto: RE: IETF network incremental plan

     
    Yoav

    From: Ted Lemon <mailto:[email-masked]>
    Sent: Thursday, November 17, 2016 9:33
    To: Randy Bush <mailto:[email-masked]>
    Cc: IETF discussion list <mailto:[email-masked]>; Jordi Palet Martinez <mailto:[email-masked]>
    Subject: Re: IETF network incremental plan

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 11:34:42 +0900

> even in the corporate network?

A bug in my CeroWRT 3800 home router results in our wifi regularly having NAT44
broken, but IPv6 continues to work. (There is no NAT64).  It often takes my
wife days to notice: she complains "twitter looks weird", as the twitter CDN
is not v6 capable, so the CSS doesn't load.

{I have a Turris waiting at home, I didn't want to install it before
travelling}

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 17 Nov 2016 13:52:48 +0900

On Thu, Nov 17, 2016 at 10:34 AM, David Conrad <[email-masked]> wrote:

>
> I sort of like the idea of making the default IETF SSID IPv6 only, with
> other SSIDs that support v4/dual stack. It would probably be an eye opening
> experience for some.
>
>
Perhaps it would be eye opening for some. For a subset of those, perhaps it
would even cause them to do something helpful: write drafts, debug
software, fix their networks, harass their service providers and IT depts,
etc. But for others, it will merely be an inconvenience.

E.g., I imagine somebody not paying close attention to announcements on the
mailing list, showing up to a Monday morning meeting, connecting to the
IETF network, wondering why their employer's VPN isn't working, not getting
email, ... This experience is certainly not the end of the world for
anybody. But it may cause extra work for chairs, the NOC, et al.

It's not clear to me how we weigh the costs vs benefits. I think it would
be valuable to consider data from the NOC such as proportions of v6 / v4
traffic. But for now I'm a skeptic of intentionally breaking network
connectivity for attendees.

-Benson

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Nov 2016 13:58:52 +0900

On 11/17/2016 1:52 PM, Benson Schliesser wrote:
> But for others, it will merely be an inconvenience.

Indeed.

Coercive experiments on production services tend to have collateral 
effects that typically are significant and undesirable.

The IETF meeting network is a production service for more than 1000 people.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Tim Chown <[email-masked]>
Date: Thu, 17 Nov 2016 05:13:33 +0000

> On 17 Nov 2016, at 04:58, Dave Crocker <[email-masked]> wrote:
> 
> Coercive experiments on production services tend to have collateral effects that typically are significant and undesirable.
> 

The discussion isn’t about which networks are available, it’s about which is the default.  I can certainly change my default on my MacBook, though rather annoyingly not on my iPhone (or is there a way to do that?), I just need to be aware of what/where the IPv6-only SSID lives.

Some more prominent messages to, for example, the 97attendees list would be helpful in promoting more people to at least try the NAT64 SSID, perhaps with links to relevant info/resources and a wiki to share experiences. 

It would be interesting to see some stats on associations to the different SSIDs.

Tim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 14:21:55 +0900

Arguably if your work network doesn't work with IPv6, that's a problem
with your work network, not a problem with the IETF network.   You
should be submitting a support request to your company's IT
department, not to the IETF.

On Thu, Nov 17, 2016 at 1:52 PM, Benson Schliesser
<[email-masked]> wrote:
> would even cause them to do something helpful: write drafts, debug software,
> fix their networks, harass their service providers and IT depts, etc. But
> for others, it will merely be an inconvenience.
>
> mailing list, showing up to a Monday morning meeting, connecting to the IETF
> network, wondering why their employer's VPN isn't working, not getting
> It's not clear to me how we weigh the costs vs benefits. I think it would be
> valuable to consider data from the NOC such as proportions of v6 / v4

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Nov 2016 15:01:59 +0900

On 11/17/2016 2:13 PM, Tim Chown wrote:
> The discussion isn’t about which networks are available, it’s about which is the default.

Thanks for mentioning this.  Switching defaults leaves the same range of 
service available and merely imposes a slight configuration change.

So I did note a reference to this point, but it didn't sound like a 
guaranteed arrangement.  Sounded like some folk wanted an arrangement 
with more restricted support.

d/

-- 

   Dave Crocker

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Nov 2016 18:19:57 +0900

> On 17 Nov 2016, at 10:39, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

I think it would be interesting to have an ietf-realworld SSID with RFC 1918 IPv4 and routable IPv6.

Whether that can or should be the default ‘ietf’ I don’t know, but I can certainly prioritize one network or another on both my devices.

Yoav

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Nov 2016 22:51:21 +0900

> question.

which is why i did not send email to the iab; i just wanted fair queue
management.  _as a community_, we need to discuss what the goal(s) of
the network are.  i am learning from the feedback; thanks all.

a few points which have not been mentioned

  o there is a significant number of attendees who do not have much
    configuration control over their laptop.

  o there is a singificant number of attendees who need vpn access to
    get work done.

  o there are attendees with strange and old operating systems.  some of
    these folk wander to the help desk and the noc.

and a personal bias.  in the ops part of my $dayjob (which is minimal; i
am supposed to do research), we try to provide what the customer wants,
not tell them to do things they do not want to do.  ykmd.

randy

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Nov 2016 01:28:07 +0900

Randy, Andrew,

I’m sorry Randy that you didn’t get a chance to ask your question.

> If that _is_ the question, I observe that the IAB can't answer the

But, I believe it is my job to answer that question. Or at least relay the process that we use to answer that question: As with everything, what we do at the IETF is up to the community. You guys tell me that you need <something>, we try to give you <something>.

So ultimately we want to do what you tell us to do, as whole. If I am allowed to speculate, the purpose of our network from the community’s point of view is probably a mixture of few things, with obviously the most important one being to deliver the fullest service to your customers, the IETF participants. But, I know there are some participants who also have other wishes, including the ability to run tests or configurations that we think are common in the future.

I’m not going to stand here and act as a arbiter between the different interests. I think there are some future scenarios where the end state is something where we’d have to decide what the default is (e.g., “ietf” vs. “ietf-nat64” vs. “ietf-dualstack". Jim had some ideas of some other possible end states where there is no such need.

But maybe more important than thinking about the possible future conflicts in defaults is to think about what’s useful in the interim, because I at least would like to see incremental steps.

What I heard in the plenary last night was that there were many people who wanted to run with NAT64 setups. But the setup that we have that for today is pretty basic. I could imagine some data/failure collection ideas, I could imagine redundancy setups, I could imagine more tools to manage our SSIDs…. and I think most of those things would be useful improvements to the current network. And if we had them, and people actually committed to set those up and do some testing… I think this would be a win/win for the IETF. Our existing services would continue to run, volunteers would help setup new services, people would be able to use them, and some experience could be collected. Further steps could be taken if results are interesting & community members use the services. I will myself commit to using such services, if available.

But again, these are just my ideas. What do people want that we do?

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2016 08:11:48 +1300

On 18/11/2016 05:28, Jari Arkko wrote:
...
> But again, these are just my ideas. What do people want that we do?

Speaking for one person only, I do not believe that an IPv6-only network
with NAT64 to reach legacy services is a desirable end point, because it
includes *unnecessary* NAT breakage.

A desirable end-point is a dual stack network (with non-RFC1918 IPv4),
where the amount of IPv4 traffic is very small, tending towards zero.
That includes no NAT breakage.

So I see no argument for changing the current default SSID setup.

(We already have millions of testbeds for the intermediate setup of
a dual-stack network with RFC1918 IPv4; I write this message from
one of those, and it works fine, except for NAT breakage.)

   Brian