Re: About IPv6 address semantic

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 31 May 2020 23:38 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 9C92D3A0811 for <ipv6@ietfa.amsl.com>; Sun, 31 May 2020 16:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnfqlFlKa7hQ for <ipv6@ietfa.amsl.com>; Sun, 31 May 2020 16:38:32 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5743A0810 for <ipv6@ietf.org>; Sun, 31 May 2020 16:38:32 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id i17so3490437pli.13 for <ipv6@ietf.org>; Sun, 31 May 2020 16:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+uepsu/X9scwNHhBi3VRUDiHc7U6Lh+jqqWvKujYZWs=; b=WQk5vtUPoCZLMCIYxan6WtdL9R34wahjjyIyr31iTVvF1bcv7mlR7rkQ+BvM0eNoJt 946Jv4TUTIcrnqYnwd8hKO70fJ8/3rwQFb5miM8KCK2rB4veu+ZJsLSL3gCyTLM8S8Mx mTps8RMIMSmPRiL8ZDhG+co24wYaMw7tE3IEUjk2nqB70KMmUpiqLa83QWwylBGCqHXe zs0mTe0GDbcGxpkg2PsUlD7TCnOMue6Mz2r6TOw/G8ZrUzfLDpB7XJWTu2jZj81DFn1u iRp2UUSbm4lrUYGdM7NIEzFhfbbtobUNzUpWMOlR4sXRiN2LkXbBaw2XIdGNTtlqI7sM JXPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+uepsu/X9scwNHhBi3VRUDiHc7U6Lh+jqqWvKujYZWs=; b=BJXRXpKZEtpq/xs83cediwEUu/SQnhrMozRCLS64vj198U+hrTjqRcpzyjzwmQJx6d Whvn7rpcw+Rw6Uq738fqXRio8JHMYUm+iaLYT4cmYJYaKm293wRpfoPd27534eE5v3G8 eJalF5jioHt/wwd/M4jP06lfZ8ucbjnGu91UjK8dUufDdKR/XZjNf1YmKFsoU45TVI1a rDtg1U3yoT/p0qPjqfm+ifULPVJPKpo/5XpliA0UU7aS5P8A0g6CA1oAAcWGhbIDy+pD 4qk4LOLkxZGxW5fwGAyGHe6P2cwWuDpjRjN7ByjEjJ1KKT/qcEUX9S0fDgDxFAyRiuEH Iy2w==
X-Gm-Message-State: AOAM533B97248uyxuvAXzAIyDJ7C8eRMsi3CUqjwsMNRc4AhacgBE62b aYmqpU66eDh5DLLt18NsCV22P8W1F5Q=
X-Google-Smtp-Source: ABdhPJwvvaoJ9Mh4ngOUkFKC/zHas2THkfdYPDJV/quQldigGo5PrHCNdsPF/V2HD4agqeXVVfveZg==
X-Received: by 2002:a17:902:b68d:: with SMTP id c13mr17976636pls.210.1590968311835; Sun, 31 May 2020 16:38:31 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id s75sm11299595pgc.13.2020.05.31.16.38.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 May 2020 16:38:31 -0700 (PDT)
Subject: Re: About IPv6 address semantic
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>, Miya Kohno <miya.kohno@gmail.com>, Fernando Gont <fernando@gont.com.ar>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
References: <d525604fb19f45d0991a05e2974a8379@huawei.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <0c45a99b-f6dc-6004-4747-b7bf8087a158@gmail.com>
Date: Mon, 01 Jun 2020 11:38:27 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <d525604fb19f45d0991a05e2974a8379@huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/z2gO6f7pNChUPVVLPzHsaN31uAg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 31 May 2020 23:38:35 -0000

Let's not forget the basics of IP addresses, though.

An IP address is a locator.

An IP address can change at any time.

Therefore, using an IP address as an identifier is always dangerous, and using bits of an IP address to mean something other than network topology is always dangerous. Specifically, the bits in an IPv6 interface identifier are meaningless (RFC7136). The only exception is when the system for assigning IP addresses is the same as the system for setting identifiers and for configuring nodes to interpret address bits as having special meanings. I don't know if that applies to a segment routing domain.

Maybe it's time to update https://tools.ietf.org/html/rfc2101 ?

Regards
   Brian

On 31-May-20 19:48, Xiejingrong (Jingrong) wrote:
> Hi Miya, 6man WG,
> 
>  
> 
> I had some impression about the “address semantic violation” on 6man WG before, and have seen similar arguments many times in recent few days, but when reading your points below, seems like it may be the root cause of the years of confusion and argument about how to correctly/better use IPv6 address “semantic”!?
> 
>  
> 
> The said “violation” to IPv6 address semantics seems to be “SRv6 SID” defined in RFC8402 ----SRv6 SID is an IPv6 address explicitly associated with the segment.
> 
> The said “address semantic” seems to be the “IPv6 address” defined in RFC4291----IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces
> 
>  
> 
>  
> 
> Firstly, Let me share some various kinds of “interface” I have seen:
> 
> An “interface” could be a configured one with a name, like “interface Ethernet1/0/1”, “interface GbE1/0/1”, “interface loopback12345678”.
> 
> An “interface” could be a dynamically created one with a name like “mtunnel0”, you can even show the statistics of this interface using its name “display interface mtunnel0”. This is a logical P2MP-interface as the abstraction of “a full-mesh P2MP-trees” for RFC6037.
> 
> An “interface” could be even more “implicit”, for example, using RSVP-TE signaling to carry a name “tunnel-2020” from PE1 to PE2 through P1, and you can “display interface tunnel-2020” or maybe “display tunnel tunnel-2020” on P1, which does not have an “interface” configuration or creation at all. This is a logical P2P-interface name representing an LSP scattered through the network.  
> 
>  
> 
> An SRv6 SID makes no difference than them IMO. Every “SRv6-SID” is a “128-bits IPv6 address” and could be “128-bit identifiers for an interface” if one like.
> 
> For example, the following is a configuration example of SRv6 locator and functions:
> 
> SRv6 locator loc1 2001:db8:3:4::64
> 
>   Function loc1 end ::1   ## This SRv6-SID “2001:db8:3:4::1” is a 128-bit IPv6 address.
> 
>   Function loc1 end-dt4 ::2  ## This SRv6-SID “2001:db8:3:4::2” is another 128-bit IPv6 address.
> 
>  
> 
> If one would like, one can assign a name for each of the SRv6-SID, for example, one may name it “interface-SRv6-SID:2001:db8:3:4::1”.
> 
> One can then use “display interface interface-SRv6-SID:2001:db8:3:4::1” for IPv6 address management and maintenance.
> 
>  
> 
> As I read RFC4291 further, the “IPv6 address” is nothing more than a 128-bits, and the “interface” is nothing more than a part of the 128-bits:
> 
> ----Interface identifiers in IPv6 unicast addresses are used to identify interfaces.
> 
> ----[My read] Interface ID is nothing more than “part” of the 128-bits IPv6 address.
> 
>  
> 
>  
> 
> Secondly, let me share some of the various “semantics” of an IPv6 address I have seen:
> 
> An IPv6 address could be used to identify/represent a router (similar to router-id), for example, RFC7794.
> 
> An IPv6 address could embed the 32-bit Multicast group ID into a 128-bit IPv6 address, RFC3307.
> 
> An IPv6 address could embed the 32-bit unicast IPv4 address into a 128-bit IPv6 address, RFC3956.
> 
> One may easily extended this to:
> 
> An IPv6 address could be used to identify a router with some “instruction”.
> 
> An IPv6 address could embed the 32-bit VPN ID into a 128-bit IPv6 address.
> 
> An IPv6 address could embed the 24-bit VNI ID into a 128-bit Ipv6 address.
> 
> An IPv6 address could embed the 16-bit, 20-bit or 32-bit of Tag into a 128-bit IPv6 address.
> 
>  
> 
> They could each be a “128-bit identifier for interface” if you like to manage the IPv6-address as an “interface”.
> 
> Seems to me it’s nothing more than a style of “management” of the huge IPv6 address space a node owns.
> 
>  
> 
> As I read RFC4291 further, the RFC4291 says an IPv6 address could have “internal structure”, seems to me very similar meaning as “semantics”.
> 
>    Though a very simple router may have no knowledge of the internal
> 
>    structure of IPv6 unicast addresses, routers will more generally have
> 
>    knowledge of one or more of the hierarchical boundaries for the
> 
>    operation of routing protocols.
> 
>  
> 
>  
> 
> Maybe it could be concluded by 6man WG whether there is “address violation” in SRv6 SID [RFC8402], or whether 4291 address is better than non-4291 address ?
> 
> I think that may be a great help to the folks from worrying about the (ab)use of IPv6 address “semantics”, or the “the evolution of IPv6”.
> 
>  
> 
> Thanks
> 
> Jingrong
> 
>  
> 
>  
> 
> *From:*ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Miya Kohno
> *Sent:* Thursday, May 28, 2020 11:56 PM
> *To:* Fernando Gont <fernando@gont.com.ar>
> *Cc:* IPv6 List <ipv6@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
> *Subject:* Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
> 
>  
> 
> Hi Fernando,
> 
>  
> 
> Thanks. There was a bit of leap.
> 
>  
> 
> In support, for example, the argument that CRH is better because there is no address semantic violation. These discussions are scattered and hard to reference, but it's summarized here.
> 
>  
> 
> p.24-
> 
> https://pc.nanog.org/static/published/meetings/NANOG77/2080/20191029_Bonica_Srv6__v1.pdf <https://pc..nanog.org/static/published/meetings/NANOG77/2080/20191029_Bonica_Srv6__v1.pdf>
> 
>  
> 
> Miya
> 
>     > 
>     > - And more importantly, it interferes the evolution of IPv6.
>     >    -- There is a simpler, more scalable way to do it, but CRH can delay it, sticking to the existing convention.
>     >    -- This can take away the potential of IPv6 itself.
>     >    -- IPv6 should evolve. Otherwise, we have no choice but to give way to the new Non-IP or IPvx proposals.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>