IETF Logo Mail Archive

Re: Question about RFC6724

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 02 May 2022 20:47 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09294C14F742 for <ipv6@ietfa.amsl.com>; Mon, 2 May 2022 13:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, 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=gmail.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 tZMMFPmwKQIS for <ipv6@ietfa.amsl.com>; Mon, 2 May 2022 13:47:54 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 B1C82C14F729 for <ipv6@ietf.org>; Mon, 2 May 2022 13:47:54 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id t11-20020a17090ad50b00b001d95bf21996so436059pju.2 for <ipv6@ietf.org>; Mon, 02 May 2022 13:47:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=d9sVF2gZVa6lArS0PrchYhvpbUct3HXiOi1TmgodAdA=; b=Nw3KA4A045RsplF/k4yM7S2OZRj5ECJprIYe8O5SmHCk+hpiycf5id9JrNVRR5fZ5K G8RsqLP7k/V314yXQhZ/KxxjHjuSs3EHlT+FIi+LQw6qho0gGeFuq9312KcRrYpxdsCf PvDP1kfplsTwkLbuFkuJUkt2dWNvTo7Sru8/mqg/lN4Sw61SifKLYdEKiQ58Vwc7armv LHCBfQhRBKSF4o0dJCLxjAr5xBRwivzx9kxhDXXpnbOjqoG/QkfIeR99DUH5LYuUg3Ld QocvkjhbPBx/vwRJ5kz0YZV5yk0HkGxS4558U5RudKsQJzZMVn+trVO8zI94x2c8Fcn+ 73tQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=d9sVF2gZVa6lArS0PrchYhvpbUct3HXiOi1TmgodAdA=; b=Cp3Oew775V7XUd+GNwhvyE45GW7nDH4WpQtDjkb0B7GVdAFVtyFU/p28wtfyX8PzH3 PPdt1mRy7o0zBcRQFJGlm9ahk3kuzDJqaJdIrEbGiuGCmMvjNCWtECoV3p00vsDfi4+6 pTEO5dQEqeDX1rv927tN2n9n16k46FGR6IRMHZW68utc2oCxdoVKku9J+gZX49l2+d/4 6vlRrc+pG5sG02HisQSJLLGEyAzAvapvo7fyzV32ovgxJixH95U5RW0qZswg/ij4+oWI YUJixlbgUJAMmmncA+aE3tH6zf7Gqped01GwmNuXJ8Hj/t7YlBQjY06Ym0KtI+fyMoU+ jnLQ==
X-Gm-Message-State: AOAM531KsZb52Nlo/LHOUNDKchHgjDF1FqH9E7Ha4SXcZusppfOEztZz gMuiRHRAUC9PLKnHj/O7OGwXkCrd7ehTmQ==
X-Google-Smtp-Source: ABdhPJzQaea7Cf0fq9zKpwu4sBE+LYkM2vDDKARjzV9yKkL4eeQA2L/jTekAR3HryWZvxSwhJGndAw==
X-Received: by 2002:a17:903:124b:b0:15e:84d0:ded6 with SMTP id u11-20020a170903124b00b0015e84d0ded6mr13389515plh.141.1651524473642; Mon, 02 May 2022 13:47:53 -0700 (PDT)
Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c1-20020aa781c1000000b0050dc7628188sm5232123pfn.98.2022.05.02.13.47.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 May 2022 13:47:52 -0700 (PDT)
Subject: Re: Question about RFC6724
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, 6man <ipv6@ietf.org>
References: <3709f4b8570a4fd1b1f5b46f2152ee5d@boeing.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <f019553e-212a-0b1a-9b61-30e63dc8be78@gmail.com>
Date: Tue, 03 May 2022 08:47:48 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <3709f4b8570a4fd1b1f5b46f2152ee5d@boeing.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IZw3Ki_5kAcP3-2p8WnDbh8hH1Y>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2022 20:47:59 -0000

On 03-May-22 02:32, Templin (US), Fred L wrote:
> Brian, my understanding is that routing information can include prefix lengths longer than
> /64 (e.g., /96, /112, /120, etc. up to /128). So, if a forwarding information base includes:
> 
>     ::ffff:192.0.2.0/120
> 
> Then, that entry would match all addresses from ::ffff:192.0.2.0 up to ::ffff:192.0.2.255.
> 
> That seems only natural to me - does it seem surprising to you?

No, but the language I quoted refers specifically to the "interface identifier"
and the IPv4-mapped format simply doesn't have one of those. IMHO, that's an
unreported erratum - the "(i.e. ...)" parenthesis does not apply to the
IPv4-mapped format.

And yes, unless someone convinces me I'm wrong, I will report the erratum.

    Brian

> 
> Fred
> 
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Sunday, May 01, 2022 9:33 PM
>> To: 6man <ipv6@ietf.org>
>> Subject: [EXTERNAL] Question about RFC6724
>>
>> Hi,
>>
>> Excuse my ignorance, but I have a question about RFC6724. The rules depend on longest prefix matching and therefore on the definition of
>> CommonPrefixLen(S, D).
>>
>> The way it's defined doesn't work for ::ffff:0:0/96, as far as I can see:
>>
>>>
>>> 2.2.  Common Prefix Length
>>>
>>>     We define the common prefix length CommonPrefixLen(S, D) of a source
>>>     address S and a destination address D as the length of the longest
>>>     prefix (looking at the most significant, or leftmost, bits) that the
>>>     two addresses have in common, up to the length of S's prefix (i.e.,
>>>     the portion of the address not including the interface ID).  For
>>>     example, CommonPrefixLen(fe80::1, fe80::2) is 64.
>>
>> The "interface ID" is simply a non-concept for IPv4-mapped IPv6 addresses. So what do implementations do? What is the common prefix
>> length of ::ffff:10.1.0.10 and :ffff:10.1.0.1, in terms of the RFC6724 rules?
>>
>>        Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email