Re: [v6ops] complains about '64::' addresses draft-vf-v6ops-ipv6-deployment

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 29 March 2021 13:54 UTC

Return-Path: <alexandre.petrescu@gmail.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 A152C3A156E for <v6ops@ietfa.amsl.com>; Mon, 29 Mar 2021 06:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.668
X-Spam-Level:
X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 l_wyYrV1ZsOY for <v6ops@ietfa.amsl.com>; Mon, 29 Mar 2021 06:54:09 -0700 (PDT)
Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) (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 9E9B13A135C for <v6ops@ietf.org>; Mon, 29 Mar 2021 06:54:09 -0700 (PDT)
Received: from [IPv6:2a01:e0a:937:bc30::c8b2:2e1d] (unknown [IPv6:2a01:e0a:937:bc30::c8b2:2e1d]) by smtp2-g21.free.fr (Postfix) with ESMTP id 359FB2003D0; Mon, 29 Mar 2021 15:54:00 +0200 (CEST)
To: Gert Doering <gert@space.net>
Cc: Gabor LENCSE <lencse@hit.bme.hu>, v6ops@ietf.org
References: <CAB75xn7=swhtwqRuV6SoWoMO7jtCcPCc02XiVpAjE=VUx8CyaQ@mail.gmail.com> <6059897e.1c69fb81.ac270.d863SMTPIN_ADDED_BROKEN@mx.google.com> <749643a7-313f-4bd1-8bb8-7dc26d830070@gmail.com> <605aae8f.1c69fb81.8a8ed.04b7SMTPIN_ADDED_BROKEN@mx.google.com> <35c4cf4f-0128-dff6-27a3-4cc868539f7f@gmail.com> <9614BF99-431D-4046-9762-0F111AFBB27D@consulintel.es> <a498117e-4834-41f8-5c90-ad7734d07220@hit.bme.hu> <e770fec1-2189-f683-6c74-36e32541c53d@gmail.com> <abe65114-d9c9-10ee-2c78-449051acbb61@hit.bme.hu> <3c50c72b-b606-a6cf-3095-f08ad48eecf5@gmail.com> <YFtOdaC/DzoWeKk4@Space.Net>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <a2b125ee-f4af-ef7f-4569-3b7868094c99@gmail.com>
Date: Mon, 29 Mar 2021 15:53:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <YFtOdaC/DzoWeKk4@Space.Net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/j06MHqF3l3hxtO0y6cTTuBJ5cYo>
Subject: Re: [v6ops] complains about '64::' addresses 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: Mon, 29 Mar 2021 13:54:16 -0000


Le 24/03/2021 à 15:36, Gert Doering a écrit :
> HI,
> 
> On Wed, Mar 24, 2021 at 03:32:08PM +0100, Alexandre Petrescu wrote:
>> Le 24/03/2021 à 13:11, Gabor LENCSE a écrit :
>>> I meant that you need to do the address synthesis manually. I 
>>> intended the 64:ff9b::/96 WKP only as an example.
>> 
>> As a side note,  I think that 64:ff9b::/96 prefix might need a
>> 32bit IID, which is probably forbidden by the IPv6 Addressing
>> Architecture RFC 4291 ("For all unicast addresses, except those
>> that start with the binary value 000, Interface IDs are required to
>> be 64 bits long").
> 
> 64:: does start with 000
> 
> And it has no IID at all, not "/32".

I must complain about this, sorry :-)

For some reason - why? - we end up with two kinds of unreachable
addresses: '64::'s and 'fc's (which can also be noted as 'fd's).

They are called "Local-Use IPv4/IPv6 Translation Prefix" and "ULA"s,
which are two different things.

Both these LUTs and ULAs cant go in the Internet - in principle - but
they are distinct spaces.

I wonder why LUT designers didnt use ULAs?

2. These 64:: prefixed addresses might actually _be_ attached to
interfaces, and not just results of algorithms or rt table entries.

I noticed DNS64 resolvers that tell on the Internet that they own such
address, so one would query it from inside that particular network, but
not from the Internet.

I think there might be a misunderstanding here: IANA does not allocate
them but people make it look as if they are allocated.

Also, there might be a problem at IANA as well.

IANA makes some confusing statement about this 64:: space.

For example it says that "64:ff9b::/96" is globally reachable, but when
when I try to reach it from an IPv6-only computer it isnt.  This
'globally reachable' is said on the same web page that says fc00::/7
(ULA) is not globally reachable.
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Maybe someone has a "64::" addresses computer that I could ping6 or
query with an nslookup server command?

Alex

> 
> Gert Doering -- NetMaster
>