Re: IPv6 only host NAT64 requirements?

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 15 November 2017 07:36 UTC

Return-Path: <prvs=1492ded23e=jordi.palet@consulintel.es>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BD6129447 for <ipv6@ietfa.amsl.com>; Tue, 14 Nov 2017 23:36:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLzOTjTb5Cgo for <ipv6@ietfa.amsl.com>; Tue, 14 Nov 2017 23:36:52 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C245A1270A0 for <ipv6@ietf.org>; Tue, 14 Nov 2017 23:36:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510731409; x=1511336209; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=XOFT0rtpxJfDpWaRrX0rNeuCB tn+wVmXALgVGb0mUtM=; b=p2flrawcVlj2FFxyEEOk9scEV0d9awyV8+pg/5+6/ VBPW/oS/nWB1/peVUBZ/IpqhE2tc+dYzmKj2aw1Bl0A0Vt6UU9ObL5CVcgVJrNG9 YIHu75IpZXHoLE/w/su7qciD9wnzcSDZXUxiAIpEuC4i5QTXvVtAB3/OzqKASa1e 7I=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=UEliniMWRdRRyAt+T/AqzPCri7WoXGgsd4cpe/UysnBPzSZzoKy2/oLWrtRQ XFSN9yunUMwNlGlpKHbxuw50nfogcqJhREKvs2yoxP/W6D9BSDDWWJ58L 8uw3JfJN4LCtRMcV55PaPIKClHXqQ3XWZWCxWk0+GYX8N4emU8yJmk=;
X-MDAV-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:36:49 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:36:48 +0100
Received: from [31.133.140.255] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005624238.msg for <ipv6@ietf.org>; Wed, 15 Nov 2017 08:36:47 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:171115:md50005624238::OL4fsNBNOvkJZmwh:00004f03
X-Return-Path: prvs=1492ded23e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 15 Nov 2017 15:36:28 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: 6man WG <ipv6@ietf.org>
Message-ID: <C50D6633-2C8C-47B6-9A95-CBC9F526B166@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <B84A189C-AC6A-407B-B1E3-B5EACA4F66FB@consulintel.es> <BEC4C879-5657-49A5-9E71-ACD4214D3B07@employees.org>
In-Reply-To: <BEC4C879-5657-49A5-9E71-ACD4214D3B07@employees.org>
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/ipv6/SmT5JAnAB_IcywhWYq8kUseoC40>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 07:36:54 -0000

> I was also thinking on this yesterday after the hackathon and I thing from that talk it is obvious that I will support that.
    
    Thanks.
    
    > 
    > Also thought about this:
    > 
    > Could the “IPv6 node requirements document” include also a consideration for the same you mention here, in case there is IPv4-only in a dual-stack LAN with IPv6-only access?
    
    Not sure I understand what dual stack LAN with IPv6 only access means.
    If it is dual-stack, I'd assume you also have IPV4 routing.

[Jordi] What I mean is a LAN (which is dual-stack) but with *hosts* that are IPv4-only (old devices, IP cameras, printers, many other very frequently found in home networks, even corporate ones). The problem I see is that those hosts not always will get updated, unless maybe very severe security issues …
    
    > I’m almost sure that this is out of the scope of the 6man charter, but I also feel that this is somehow our job … alternatively what is the correct place to do that? May be a new sunset4 document? Or int-area? The point here is an IPv4-only host being used in a network using IPv6-only for the access ...
    
    If you are talking about the reverse problem, an IPv4 only host requiring access to the IPv6 Internet.
    Or an isolated IPv4 only host in an IPv6 only network... I'd think that would be better suited for sunset4.

[Jordi] yeah, I guess we agree …
    
    Cheers,
    Ole
    



**********************************************
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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.