IETF network incremental plan

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 16 November 2016 10:32 UTC

DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ojoslzknfZZC5XHKkmosmYrgM9eboCazv+4E0YhDcDEsy7KpLAxSAzXVKV1F IDkFEi7JhVlgmyKmd/yvIRR8qa2XmF8mLz6T+acyv0dst1dXQqsO+sBmE +6G383n3LzJ3Jz58TNKsTrKr9+x9DOPFr4GpD9bIhPahPShzPBqtUM=;
User-Agent: Microsoft-MacOutlook/f.1b.0.161010
Date: Wed, 16 Nov 2016 19:26:44 +0900
Subject: IETF network incremental plan
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IETF discussion list <ietf@ietf.org>
Message-ID: <0C5BCD32-2D2A-42B9-8DEA-A1E1A527A8BB@consulintel.es>
Thread-Topic: IETF network incremental plan
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/M619XVg2hOcMx-xen0Qd7cNDnRw>
Precedence: list
Reply-To: jordi.palet@consulintel.es

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.

IETF network incremental plan JORDI PALET MARTINEZ
Re: IETF network incremental plan Randy Bush
Re: IETF network incremental plan Ted Lemon
Re: IETF network incremental plan Paul Wouters
Re: IETF network incremental plan JORDI PALET MARTINEZ
Re: IETF network incremental plan Michael Richardson
RE: IETF network incremental plan ynir.ietf
Re: IETF network incremental plan Brian E Carpenter
Re: IETF network incremental plan Andrew Sullivan
Re: IETF network incremental plan David Conrad
Re: IETF network incremental plan JORDI PALET MARTINEZ
Re: IETF network incremental plan Benson Schliesser
Re: IETF network incremental plan Dave Crocker
Re: IETF network incremental plan Tim Chown
Re: IETF network incremental plan Ted Lemon
Re: IETF network incremental plan Dave Crocker
Re: IETF network incremental plan Yoav Nir
Re: IETF network incremental plan Randy Bush
Re: IETF network incremental plan Jari Arkko
Re: IETF network incremental plan Brian E Carpenter