Re: [v6ops] [IPv6] RFC for fec0:0:0:ffff::1?

Klaus Frank <klaus.frank@posteo.de> Wed, 30 November 2022 20:30 UTC

Return-Path: <klaus.frank@posteo.de>
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 EBDF4C14CE53 for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 12:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de
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 q_Z_nxKwYlJ3 for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 12:29:57 -0800 (PST)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187A5C157B39 for <v6ops@ietf.org>; Wed, 30 Nov 2022 12:29:56 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B1E12240027 for <v6ops@ietf.org>; Wed, 30 Nov 2022 21:29:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1669840193; bh=/BEvceSoo+7UAl9sGbbk+CQli9PyCH7sXa5zJX9gOIo=; h=Date:Subject:To:From:From; b=mhd0uPJQVj0oOlQS1PYOAywOqm4oqn6834UKyjPU01qhSX7Ds80MHf4tbF+Lgy8Aq q5JFS8cPEueJ22ZMSeynR0/UGwSzXE90E/dW31nVmcBdAii1B5wiYwlZmDzSDhAb5m bluJeas16kuAsLOKflhCkHnCEmLT86qcszlGgkCQnQnSXBOzjDo+baDApxudqvvzSf /t5GBj0OIJj2pj0wH6qB8DsWTgsNP2B5wbFlSYF+aWXCEi33XAop4pMV0SL7aPzYay VDWwA4lnb1uqcKojmLdVKAB6atik5os0vPBIJN03QF6oa/HeRqHFGExbnYTMfZO6Fh iY0A/I6LD78mg==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NMrRP1Zhnz6tmH for <v6ops@ietf.org>; Wed, 30 Nov 2022 21:29:52 +0100 (CET)
Message-ID: <1d2838fb-270f-1bc3-9c51-d76f06a2ebcc@posteo.de>
Date: Wed, 30 Nov 2022 20:29:51 +0000
MIME-Version: 1.0
Content-Language: de-DE
To: v6ops@ietf.org
References: <324539dd-37f6-fbd9-ea98-c51320f38603@posteo.de> <Y4d8VaEbNV43BGRl@dwc-laptop-2.local> <CAM5+tA-9-kchyifny_pfHLi7n4by3-xCkhmxq8sRHCm=NshbsA@mail.gmail.com> <CAE=N4xd0gEmZB7JY25J8kBYiCio36KqQpr3dwymV30ibeWttOg@mail.gmail.com>
From: Klaus Frank <klaus.frank@posteo.de>
In-Reply-To: <CAE=N4xd0gEmZB7JY25J8kBYiCio36KqQpr3dwymV30ibeWttOg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms030107030801050609050407"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tup3BoKQjCWr4raDyspLmQirhEA>
Subject: Re: [v6ops] [IPv6] RFC for fec0:0:0:ffff::1?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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, 30 Nov 2022 20:30:02 -0000

On 30.11.2022 20:28, Ed Horley wrote:
> From an email exchange with Dave Thaler (Microsoft) back in 2015 when 
> I asked about this:
>
> "I’m not in any hurry to see it removed (under the “if it ain’t broke 
> don’t fix it” principle).
> Even the RFC section you cite says:
>    Existing implementations and deployments MAY continue to use this
>    prefix. "
>
> So I don't see Microsoft removing this from the OS unless there is a 
> specific existing security exploit or concern that is demonstrated to 
> be exploitable.
> Also, the draft you found has Dave listed as a co-author. Perhaps that 
> helps close the loop?
>
> NOTE - I'm not speaking for Dave or Microsoft - just trying to provide 
> some context.
>
> Out of my list of IPv6 asks for the Windows OS, this one isn't high on 
> my personal list to get "fixed". I feel it is a cosmetic issue more 
> than anything else at this point.
Actually I didn't want to have it "fixed" I.E. removed in windows. But I 
rather would have liked to check if it is a cross platform thing or a 
"just Microsoft" one again. As it would have been kinda usefull in one 
of my projects right now. I kinda like the idea of a well-known (or site 
speficic as it originally was) DNS Server address....
>
> On Wed, Nov 30, 2022 at 8:36 AM Nick Buraglio <buraglio@es.net> wrote:
>
>     I have also heard through the grapevine that those pre-dated the
>     deprecation of site-local and that there is "no plan to remove
>     them". This is anecdotal, I have never seen reference to it, just
>     side conversations I have had over the years.
>
>
>     ----
>     nb
>
>     ᐧ
>
>     On Wed, Nov 30, 2022 at 9:53 AM Dale W. Carder <dwcarder@es.net>
>     wrote:
>
>         Thus spake Klaus Frank (klaus.frank@posteo.de) on Wed, Nov 30,
>         2022 at 04:08:07AM +0000:
>         > does anyone know what RFC is responsible for the IPv6 DNS server
>         > configuration on all windows clients defaulting to
>         fec0:0:0:ffff::1, I was
>         > unable to find any. Nor is it listed in the iana
>         special-purpose address
>         > registry.
>         >
>         > I however found a draft (draft-ietf-ipv6-0dns-discovery-07)
>         from 2002, but
>         > no actual RFC.
>
>         That draft matches my memory.  Recall that was well before
>         rfc5006
>         which was quite late to the party to address a glaring oversight
>         as the ra vs dhcpv6 holy wars raged on.
>
>         Having well-known resolver addresses be site-local (and
>         anycasted,
>         despite what the draft claims on that issue) could have been a
>         logical design pattern for local networks.
>
>         But more generally, no two people could ever be expected to
>         agree on
>         a common definition of what a "site" is.  rfc3879 documents
>         the pain
>         very well.  (see a generalized incarnation of this issue in
>         rfc8799).
>
>         Dale
>
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         ipv6@ietf.org
>         Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>
>
>
> -- 
> Ed Horley
> ed@hexabuild.io| (925) 876-6604
> Advancing Cloud, IoT, and Security with IPv6
> https://hexabuild.io
> And check out the IPv6 Buzz Podcast at 
> https://packetpushers.net/series/ipv6-buzz/
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops