[v6ops] Re: 464XLAT-only networks

Ted Lemon <mellon@fugue.com> Fri, 25 October 2024 14:43 UTC

Return-Path: <mellon@fugue.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 A7123C14CE2C for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2024 07:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXeSR_kx30QX for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2024 07:43:55 -0700 (PDT)
Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com [IPv6:2001:4860:4864:20::2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED3EC14F686 for <v6ops@ietf.org>; Fri, 25 Oct 2024 07:43:55 -0700 (PDT)
Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-288d74b3a91so1323020fac.0 for <v6ops@ietf.org>; Fri, 25 Oct 2024 07:43:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1729867434; x=1730472234; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tO28ZXh94yEpKQKLZoa5KFUnTJFaS8sbZ0CRvaPXfkg=; b=NCnrMZ1B0xUlIQ9+EDQ0I1TphlgMayvTmhixVft73bd7j2JVcxBN5m6uVcriD6Bdih LVHjhn9VaePmpM7eWfneHY2hV2K51ICJrXCr++TEJT06rDot0uxGFoHVI+KY9RODC8/v Vr5ng25yHrKRXSeUa/v9fTtJTrZEmrM9kI/XGv/ZFS8qQiKWu9ANqj+zs9PgnMa903WE RKOLNTnRLJgiUnZfEfuMSARQhxkHjJvM/RwNaOiLMBIWXQ2EdTlggLhQ1bZcU6zlqyTF +3kgdUdCyBUL7ILrDCwqMcEsRyz8FCk34S8zFyIyV7knCRIBiQBQFP4Dt72IWkIL+M/t AMMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729867434; x=1730472234; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tO28ZXh94yEpKQKLZoa5KFUnTJFaS8sbZ0CRvaPXfkg=; b=frQne426fOvzhC+afZXi1FafT4T9sonB25XA7V9u/LHisvLTAcR6/40xM6m6bbjLVc HLHoDwo0TecCPiBVVzLh2KfW3IL8jcDqyF7snCsd/cVCgPf1M5WWwFHOFWod5YpdEkvb LD87MsxtqHjaHsYGYWHkuCS//lrrBeQP1NKBnPw8GHY2JfpgisWVcgtAlTXoGKwtMGen VOJBphsjwPZSsc2qMfSELNej9pXCRtT7oEPRXeWFY+rsIZhbKNCMRzoMwQn2ew/LUFAP 4LGmKndVA9MBW+RDUiNlqZL9tSus8c8k5q0Lrn0MKxRcrU5H7IyCCgzTcfY0r3RDjWti nCIw==
X-Forwarded-Encrypted: i=1; AJvYcCVC94aUlDpbMXVtIi9bkRb8bUXuaUU6qkLubPFo8lBSd22hrWatTmuhMrmA29qHpYECHgqq4g==@ietf.org
X-Gm-Message-State: AOJu0Yy9V5rAAoRYG7k2Xw/71qIWZ48LmY7fy+InLat+lJmL8hPJ52JU mKkAwwPLMKWyoqd3dIc/05KNFtayadyvvw4ywg2REc9cVadNPm06XZvIf4HRYqmXkdbOtoa0JJZ sVLM6Sc0I+tRJhpPY0el/nUGUYXOFwbsp4TPWtg==
X-Google-Smtp-Source: AGHT+IEmAlGk4Ud7Lsn9VQyQ8HDoEKuWLb98whbI3ONlPMLmy1VWuDiE0NKZBPD4vIc513yPKEfuzJFlVWHDWGlM7fU=
X-Received: by 2002:a05:6870:71ca:b0:27c:a414:b907 with SMTP id 586e51a60fabf-28ced42e763mr5523900fac.33.1729867434351; Fri, 25 Oct 2024 07:43:54 -0700 (PDT)
MIME-Version: 1.0
References: <CA+-cKyPQR8k=PnG+X+Sj1XXwHmioUQQej3Wmx7jzMGFc=NtXLA@mail.gmail.com> <ZxowSz2G_eY3Mkt5@Space.Net> <CA+-cKyMJwLd+EVMNCt7m=-7pt4Tfr5g5aFUxQa5m02c+VSB04w@mail.gmail.com> <Zxo6mVmCPnYEDVjo@Space.Net> <CA+-cKyPPgsKsAWARw-nKEH5NgQeV+NkWfyiDK_aXQu0Vmh7sgQ@mail.gmail.com> <541a14ae-dd64-4fc9-ae61-ffd068dd2d08@gmail.com> <CA+-cKyMev6AH42LQcvcH07qtQSn4Vqw-JhV+vrvq3pQbZnq1mA@mail.gmail.com> <CAN-Dau0qCsteaPi_pFvSHoSBnC4Si0hizuyvEWbNjfQydhvDOg@mail.gmail.com> <CACyFTPGbp-EwOuZBLsgppNVtNPMuyAbtbG9H4zS-+RjgE2xRaw@mail.gmail.com> <CA+-cKyOk9GPJGrHrO-fqUnAuo9G5DGYU3=tuUEt4E30icyuVrg@mail.gmail.com>
In-Reply-To: <CA+-cKyOk9GPJGrHrO-fqUnAuo9G5DGYU3=tuUEt4E30icyuVrg@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 25 Oct 2024 16:43:15 +0200
Message-ID: <CAPt1N1m7v4B-4z-n7-P6j_Vo=sJyhJoLZWySnzqUZ1i_prO9fA@mail.gmail.com>
To: "Soni L." <fakedme+ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000eef8b706254e2555"
Message-ID-Hash: IX2OZETPB3KV7UNQT4L7244LSW6O4ICK
X-Message-ID-Hash: IX2OZETPB3KV7UNQT4L7244LSW6O4ICK
X-MailFrom: mellon@fugue.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: David Farmer <farmer=40umn.edu@dmarc.ietf.org>, IPv6 Operations <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [v6ops] Re: 464XLAT-only networks
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/GskUrd01is7pkQwgnNutIS5Sf4E>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

This is a bit of a weird discussion. I will freely admit that I think the
proposal is a bad idea, but more than that, it's just an experiment that
you can try. You don't need to publish an RFC to do the experiment. It
feels like you are putting the cart before the horse in starting with the
RFC, rather than with the experiment. I think the experiment will fail, but
that's just my opinion. You should just do the experiment if you think it's
worth doing, and then report back. Of course, part of the experiment has to
be evaluating your students' ability to understand IPv6 networking in a
real-world environment, and I don't know how you evaluate that with this
approach.

If I were in your situation, I would build an OpenWRT router with a
Hurricane Electric tunnel and a large prefix delegation, and connect it to
your IPv4 network with a NAT64 setup. Now have the user connect their
router to the south side of your router, and they have a working native
IPv6 network and can actually learn to do IPv6 in a real-world environment,
as well as experimenting with 464xlat. And now you can actually evaluate
the success of your experiment, because this configuration looks like the
real world, and isn't constrained in any way.


On Fri, Oct 25, 2024 at 4:23 PM Soni L. <fakedme+ietf@gmail.com> wrote:

> Okay. You can learn IPv6, yes.
>
> ... And apply it where? Unlike IPv6, 464XLAT-only can be easily applied on
> existing IPv4 networks.
>
> On Fri, Oct 25, 2024, 11:00 Daryll Swer <contact@daryllswer.com> wrote:
>
>> David's analogy is a good one.
>>
>> Soni, all of this can take place inside GNS3, EVE-NG, containerlabs etc.
>>
>> That's how we learn networking in general in the absence of a dedicated
>> hardware lab (with or without IPv6).
>>
>> --
>> Sent from my iPhone
>>
>>
>> On Fri, 25 Oct 2024 at 6:17 PM, David Farmer <farmer=
>> 40umn.edu@dmarc.ietf.org> wrote:
>>
>>> Let me use the metaphor of flight training. You can learn to fly a plane
>>> in a simulator, but if the controls of the simulator are backwards. You are
>>> going to have a very hard time flying a real plane.
>>>
>>> If your goals for this are an environment to lean IPv6 in, which is what
>>> you seem to be saying. Then the IPv6 environment you are creating is so
>>> different from the normal IPv6 environment, I'm not sure it will be
>>> helpful, and it could very well be detrimental to the learners.
>>>
>>> I'm trying to keep an open mind, but I'm not seeing something very
>>> useful here, at least yet.
>>>
>>> Thanks.
>>>
>>> On Thu, Oct 24, 2024 at 15:13 Soni L. <fakedme+ietf@gmail.com> wrote:
>>>
>>>> for the record, the end result of a 464XLAT-only network is that it
>>>> ends up becoming a 464XLAT-enabled IPv6 network (eventually). there are no
>>>> security considerations beyond those that already apply to 464XLAT-enabled
>>>> IPv6 networks, it just happens to not have access to the IPv6 internet.
>>>>
>>>> 464XLAT-enabled IPv6 seems to be the recommended deployment strategy
>>>> for IPv6 these days, so despite the bastardization... it still works out in
>>>> the end.
>>>>
>>>>
>>>> On Thu, Oct 24, 2024, 16:43 Brian E Carpenter <
>>>> brian.e.carpenter@gmail.com> wrote:
>>>>
>>>>> In a few seconds I'll be putting this thread in a filter so that it
>>>>> will never trouble me again, but for now I'll just say that we originally
>>>>> invented 6to4 for such scenarios, and while it did help a bit when IPv6
>>>>> support was rare, it later became an operational nightmare and a security
>>>>> hole. It took years to exterminate. We should not repeat this.
>>>>>
>>>>> However, 6to4 within a university network that doesn't otherwise
>>>>> support IPv6 probably still works. I saw a case of that during 2023, caused
>>>>> by rogue behaviour in Windows Server 2008 and similar antiquities.
>>>>>
>>>>> Regards
>>>>>     Brian Carpenter
>>>>>
>>>>> On 25-Oct-24 01:45, Soni L. wrote:
>>>>> > maybe you're a student and your university is ipv4-only but you want
>>>>> to work with/make a practical ipv6 network as part of some project. this is
>>>>> the use-case for the "rogue" network (which would have to be approved by
>>>>> the university anyway). this would be the intended use-case for this cursed
>>>>> bastardization of ipv6...
>>>>> >
>>>>> > a lot of folks interested in ipv6 told us their university doesn't
>>>>> have ipv6. this might let them play with it in an university setting. ofc,
>>>>> gotta be careful about pissing off IT... (pissing off IT is probably
>>>>> ill-advised.)
>>>>> >
>>>>> > On Thu, Oct 24, 2024, 09:16 Gert Doering <gert@space.net <mailto:
>>>>> gert@space.net>> wrote:
>>>>> >
>>>>> >     Hi,
>>>>> >
>>>>> >     On Thu, Oct 24, 2024 at 09:15:04AM -0300, Soni L. wrote:
>>>>> >      > some providers still don't do ipv6, maybe you still want to
>>>>> migrate your
>>>>> >      > internal network to ipv6 to get it ready for future provider
>>>>> upgrades.
>>>>> >      >
>>>>> >      > or maybe you want to develop an ipv6-only consumer/SOHO
>>>>> router that works
>>>>> >      > on ipv4-only ISPs.
>>>>> >      >
>>>>> >      > or maybe you want to deploy a rogue ipv6-only network on an
>>>>> otherwise
>>>>> >      > ipv4-only organization, to prove a point.
>>>>> >
>>>>> >     None of these sound like anyone would want to do that...
>>>>> >
>>>>> >     Gert Doering
>>>>> >              -- NetMaster
>>>>> >     --
>>>>> >     have you enabled IPv6 on something today...?
>>>>> >
>>>>> >     SpaceNet AG                      Vorstand: Sebastian v. Bomhard,
>>>>> Ingo Lalla,
>>>>> >                                                 Karin Schuler,
>>>>> Sebastian Cler
>>>>> >     Joseph-Dollinger-Bogen 14
>>>>> <https://www.google.com/maps/search/Joseph-Dollinger-Bogen+14?entry=gmail&source=g>
>>>>>       Aufsichtsratsvors.: A. Grundner-Culemann
>>>>> >     D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>>>>> >     Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > v6ops mailing list -- v6ops@ietf.org
>>>>> > To unsubscribe send an email to v6ops-leave@ietf.org
>>>>> _______________________________________________
>>>>> v6ops mailing list -- v6ops@ietf.org
>>>>> To unsubscribe send an email to v6ops-leave@ietf.org
>>>>>
>>>> _______________________________________________
>>>> v6ops mailing list -- v6ops@ietf.org
>>>> To unsubscribe send an email to v6ops-leave@ietf.org
>>>>
>>> _______________________________________________
>>> v6ops mailing list -- v6ops@ietf.org
>>> To unsubscribe send an email to v6ops-leave@ietf.org
>>>
>> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org
>