IETF Logo Mail Archive

Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

<mohamed.boucadair@orange.com> Wed, 04 December 2019 17:48 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC9812085B for <v6ops@ietfa.amsl.com>; Wed, 4 Dec 2019 09:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bD_QmGEO6y7Y for <v6ops@ietfa.amsl.com>; Wed, 4 Dec 2019 09:48:32 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2807D120853 for <v6ops@ietf.org>; Wed, 4 Dec 2019 09:48:32 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 47SmY93V1wz5wCV; Wed, 4 Dec 2019 18:48:29 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 47SmY92cC6z5vMq; Wed, 4 Dec 2019 18:48:29 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0468.000; Wed, 4 Dec 2019 18:48:29 +0100
From: mohamed.boucadair@orange.com
To: Lencse Gábor <lencse@hit.bme.hu>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option
Thread-Index: AQHVqr1cn+wfGkMdV0W9ROdx/HB9UKeqPf3x
Date: Wed, 04 Dec 2019 17:48:28 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313E2BB5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <CAFU7BAR1JLUZps=CAqJfeQtUf-xQ88RYvgYrPCP+QP0Ter7YFg@mail.gmail.com> <8736e0gqu2.fsf@miraculix.mork.no> <787AE7BB302AE849A7480A190F8B9330313E29BB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>, <adece97c-5ac1-6a80-85fc-2b5ee4075a7d@hit.bme.hu>
In-Reply-To: <adece97c-5ac1-6a80-85fc-2b5ee4075a7d@hit.bme.hu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313E2BB5OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6Ze7bdnxrJeHy1xK89LCTiOgL68>
Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2019 17:48:34 -0000

Hi Gabor,

Please see inline.

Cheers,
Med

________________________________
De : v6ops [v6ops-bounces@ietf.org] de la part de Lencse Gábor [lencse@hit.bme.hu]
Envoyé : mercredi 4 décembre 2019 17:10
À : v6ops@ietf.org
Objet : Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

Hi Med,

12/4/2019 2:56 PM keltezéssel, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> írta:

A host that discovers the presence of NAT64 (because a pref64 was discovered) can safely release any assigned IPv4 address.

Maybe I'm misunderstanding something, but I do not agree.

Med: My assumption is what in the draft: the mode is explicitly set by a user.

   A DHCP client SHOULD allow a device administrator to configure
   IPv6-only preferred mode either for a specific interface (to indicate
   that the device is IPv6-only capable if connected to a NAT64 network
   via that interface) or for all interfaces.

   Clients not capable of operating in an IPv6-only NAT64 environment
   MUST NOT include the IPv6-only Preferred option in the Parameter
   Request List of any DHCP packets and MUST ignore that option in
   packets received from DHCP servers.


Unfortunately not all applications are compatible with NAT64.

Med: Sure. All the issues discussed in RFC6269 apply. Some of them can be solved:

* bittorrent: https://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00
* SIP: https://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00

Please see our results in:

S. Répás, T. Hajas and G. Lencse, "Application Compatibility of the NAT64 IPv6 Transition Technology", Proceedings of the 37th International Conference on Telecommunications and Signal Processing (TSP 2014), (Berlin, Germany, 2014. July, 1-3.) Brno University of Technology, pp. 49-55. DOI: 10.1109/TSP.2015.7296383
Full text is available from: http://www.hit.bme.hu/~lencse/publications/TSP-2014-AC.pdf

Med: Thanks for the pointer. These issues are not specific to NAT64; many of them can be solved (see the pointers above, for example).

Best regards,

Gábor

v2.23.0 | Report a Bug | By Email