[v6ops] draft-jjmb-v6ops-ietf-ipv6-only-incremental-00

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 03 July 2017 08:31 UTC

DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=HDy28OsvmwKJsYDxWKAkFxBFrn88XN86YUq0h4vsGVoAtuoLyy5eTGGxFg66 DN+ed7bOFuXKqYty3btTGA4qoZW/sklKDPGQqgcyFYJ7Qu1AnuXDctGjA i2hEG8WIwjw+G3ScSdg/t6cBBexTEA6RMoUx7H27wmSt3K5jib+aJQ=;
User-Agent: Microsoft-MacOutlook/f.21.0.170409
Date: Mon, 03 Jul 2017 10:31:45 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <8BFE0CCE-4345-40D5-A8D1-B77E1E5B0B88@consulintel.es>
Thread-Topic: draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YBuJoVTXshnaBHVTENyRjh4s97w>
Subject: [v6ops] draft-jjmb-v6ops-ietf-ipv6-only-incremental-00
Precedence: list

I like this document, however I think we should also provide some guidance about possible alternatives to allow at least some of the major problems described in section 9.  Known Client-side Issues.

We like it or not, we live in a world were app developers, even some time OS developers, and device developers, may not have any IPv6 support (for example vendors that no longer exist but we still need to use their devices), and STILL users need to be able (both in the IETF network and the real world).

Follows some proposed text:

New p. at the end of the actual abstract.
The document also provides a possible solution for clients/apps/devices which may not have IPv6 support, so they keep running.

New p. at the end of the actual Intro.
Support for non-IPv6 clients/apps/devices is also provided either in the main network or alternative ones (such as additional SSIDs).

New section
x. Support of transition for non-IPv6 capable clients/devices/apps
As an alternative to the legacy dual-stack infrastructure as a fallback described in section 2.1, either in the main network or an alternative one (such as a fallback SSID), the network infrastructure can provide private IPv4 addresses by means of a CLAT client (it can be run in hardware by one of the existing infrastructure devices or as a VM). The usage of the CLAT should be logged in order to understand what traffic, destinations, etc., are still not working with only NAT64/DNS64.

If you don’t like a new section, this text can be used as an alternative after the existing text in section 2.1 related to the dual-stack fallback. 

One alternative is also considering this text as one more point within the 3.  Network Services (IPv4 as a service).

In any case, if we use CLAT, then the text recommending the suppression of DHCPv4 should be clean up.

I think a real “eating our own dog-food” is better done with CLAT than with dual-stack, as we all know that dual-stack has been running in our networks for ages, right?

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.

[v6ops] draft-jjmb-v6ops-ietf-ipv6-only-increment… JORDI PALET MARTINEZ