Re: [v6ops] draft-vf-v6ops-ipv6-deployment

Martin Hunek <martin.hunek@tul.cz> Wed, 24 March 2021 18:09 UTC

Return-Path: <martin.hunek@tul.cz>
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 4A7033A3256 for <v6ops@ietfa.amsl.com>; Wed, 24 Mar 2021 11:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 ibTl-TxfyWAx for <v6ops@ietfa.amsl.com>; Wed, 24 Mar 2021 11:09:41 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91D43A3257 for <v6ops@ietf.org>; Wed, 24 Mar 2021 11:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from rumburak.ite.tul.cz (unknown [IPv6:2001:718:1c01:72:2e27:d7ff:fe2e:c477]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 4857018074562; Wed, 24 Mar 2021 19:08:55 +0100 (CET)
From: Martin Hunek <martin.hunek@tul.cz>
To: v6ops@ietf.org
Date: Wed, 24 Mar 2021 19:08:50 +0100
Message-ID: <2076432.Icojqenx9y@rumburak.ite.tul.cz>
Organization: Technical University of Liberec
In-Reply-To: <69744eb4-2f2e-6876-eba7-c439c5c4db9d@gmail.com>
References: <BL0PR05MB5316425C5650B5D2FE43DE4DAE6C9@BL0PR05MB5316.namprd05.prod.outlook.com> <72754d29-8b57-66fa-2b3a-fc6680c339f2@hit.bme.hu> <69744eb4-2f2e-6876-eba7-c439c5c4db9d@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart107785752.nniJfEyVGO"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/T2s80f4n4wWLATL1woWR8bt4_8U>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment
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, 24 Mar 2021 18:09:45 -0000

Dear Alex,

Just comment about turning off IPv4 in Linux:

It is possible to turn it off, at least if you are using NetworkManager you can change settings on IPv4 tab from "Automatic" to "Disabled". Then there will be no annoying IPv4 lying on your interface. :-)

If you are not using NM, you can always do "ip addr del <IPv4> dev <device>" and not to run DHCPv4 daemon.

Good luck with fight against IPv4,
Martin
Dne středa 24. března 2021 17:22:59 CET, Alexandre Petrescu napsal(a):
> 
> Le 24/03/2021 à 16:59, Gabor LENCSE a écrit :
> > Dear Alex,
> > 
> > On 3/24/2021 4:12 PM, Alexandre Petrescu wrote: [...]
> >> Does IPv6 mandate the use of DNS64 and NAT64?
> > 
> > Of course, not. :)
> 
> So I agree with you about that.
> 
> > There are several IPv4 as a Services solutions exist. We have
> > covered the five most prominent ones 464XLAT, DS-Lite, MAP-E, MAP-T
> > and lw4o6 in our I-D: 
> > https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-06
> > > Your ISP is likely using one of them.
> 
> For clarification - my ISP is called 'Free' (it has freedom features).
> 
> They offer me paid IPv4 and IPv6 native access at home on ADSL.  It's
> one publicly routable IPv4 address and an IPv6 /56 prefix globally
> routable prefix (a 'GUP' if I can say so, not a GUA'(ddress)).
> 
> Up to now, looking through the configuration interface of my freebox at
> home I could not see the options that you mention (464XLAT, DSLITE,
> MAP-E, MAP-T, lw4o6).  One might say that they are there invisible, but
> I doubt that, I need a proof of it.  How can I check for presence of 
> options 464XLAT, DSLITE, MAP-E, MAP-T or lw4o6?
> 
> The problems that appear when I try to browse IPv6 sites that absolutely
> need IPv4 might be because I turned off the IPv4 stack on my computer's
> interface (Windows Properties on the Interface, check off IPv4).  This
> operation (turning off IPv4 in a computer) is possible only on Windows,
> not on linux, AFAIR.  One cant do 'rmmod ipv4' in linux.
> 
> That also explains the fact that installing IPv4-IPv6 translation boxes
> (NAT64, 464LAT, etc.) in a network is not sufficient to access IPv4
> sites from an IPv6-only computer.
> 
> In order to access IPv4 sites from IPv6-only computers one also needs
> the IPv4 stack to work ok on that computer and, moreover, it needs some
> times software features in the Client that support the 64:: notation of
> IPv6 addresses.  For example, thunderbird (a very modern MUA) does not
> understand it and gets confused by it.  It takes it for an fqdn, and
> does not even try to connect the translation boxes.
> 
> This means that if one wants to migrate more to IPv6 then one has to
> think about the NAT64 and 464XLAT concepts more outside of the cellular
> network concept.
> 
> And yes, I agree with you, NAT64 and 464XLAT are good tools to
> migrate.  In particular, if one is on a smartphone or other computer
> using an OS that cant turn off their IPv4 stacks.
> 
> Alex
> 
> > 
> > Best regards,
> > 
> > Gábor
> > 
> > _______________________________________________ v6ops mailing list 
> > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>