Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

Stewart Bryant <stewart.bryant@gmail.com> Tue, 02 March 2021 15:51 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3623A2942; Tue, 2 Mar 2021 07:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 hqpxA-Isojdt; Tue, 2 Mar 2021 07:51:10 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 6A65B3A296D; Tue, 2 Mar 2021 07:51:09 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id o2so2737571wme.5; Tue, 02 Mar 2021 07:51:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=U6gs5jk+lNYStoYk32HZ1J+fFzzfuxVCPRv6JDZw+9Y=; b=CqRHMil+jwc336zw6MdZmPs/LPTowZQOXvrLVXalK/1MtRXICp7Q/lF4eLRTSkPWGu lJZF+CimkdIKw4dHv3phmijBun6WeC6xNGiRIl0W6d01tVGwbsVn29ItiyrEVYDEojkh pmpdGTNvQh34v9VZE3JkSSBAaoL/6q8vyxwqTYwNRR4QRdBIGaje/M/8j+n7EfDyvzSz Hx+uesiKxRQGhAiz+N8xaBAPPQJn/1/8n9WnUs+W6AXw463Bp7Ug5+4PB9oRsr6yLtS5 j4HEbewjGxKpeip3fvzFfLvJGHs5S80SgENwshqo/mXHzZLK0MBoFBk4O8lcPGWpic04 q9ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=U6gs5jk+lNYStoYk32HZ1J+fFzzfuxVCPRv6JDZw+9Y=; b=NH9ogAX8dUNdjydnqiCAdL5YOymEaeFUn3o4FQmRu2DnXSC9RLJQmZOicXXB2/Khtb YSuLXKbU2eYdkZJl950iWF2VUfDIOAmO6KUJXdMltDhAbDUwcw0ARFwWc6kO56Q4a1ih Ic3DIvazmap/QudJ15Y1HoVaKscYMe4IEhuP58r2bX4WFQZtnSs6dHgRAifuveK0FzhI vo46YQArOqPffoz0C+SRPJdRScLdm2GJ5alstDr4IDtosujbL5/6PWHGPQSmdPYXSxWi fhIny03yRuUmRIzTmoTO4pcy4KhSo/4zDDZsD5JbrQXlsMIyTjJGlTlrUoIzrcSV0TJ4 /Rbg==
X-Gm-Message-State: AOAM531Av87FMl+XqpO/CLHeU8B4vooaMJHD+4dAQk6ySK9crVMR8xlj plM8XKWdoeggfkMRTG6X2qo=
X-Google-Smtp-Source: ABdhPJys8MI8tlQhYUBQRtpkIr8CJCPqq7ZVB+hsKLl/4i7rQBAzy9P+G9CruAd25ZYTMHK+9t64GA==
X-Received: by 2002:a7b:c112:: with SMTP id w18mr4593368wmi.28.1614700262508; Tue, 02 Mar 2021 07:51:02 -0800 (PST)
Received: from [192.168.8.125] ([212.183.132.45]) by smtp.gmail.com with ESMTPSA id q25sm2885401wmq.15.2021.03.02.07.51.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Mar 2021 07:51:01 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <D8A2DB51-FEEC-48E6-99AC-0F50D771C91A@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E71088B5-3D5B-4083-B133-E934AABAB86B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 02 Mar 2021 15:51:00 +0000
In-Reply-To: <6F4E6B0C717D4641A2B79BC1740D8CF4A902DD90@dggemm513-mbs.china.huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Toerless Eckert <tte@cs.fau.de>, Jiayihao <jiayihao@huawei.com>, "draft-jia-scenarios-flexible-address-structure@ietf.org" <draft-jia-scenarios-flexible-address-structure@ietf.org>, int-area <int-area@ietf.org>, "draft-jia-flex-ip-address-structure@ietf.org" <draft-jia-flex-ip-address-structure@ietf.org>
To: "Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com>
References: <CDB32FF0-5CE0-4C0F-B1D1-B6BFEA42E817@gmail.com> <3dd5a712bd2b4fdbb882d860ab2ece82@huawei.com> <7A6DB0D7-A2A3-4995-A6D9-ABDFF4F7879B@gmail.com> <20210301153259.GB11539@faui48f.informatik.uni-erlangen.de> <554E7FC1-0146-4AEF-B84C-805B51013180@gmail.com> <6F4E6B0C717D4641A2B79BC1740D8CF4A902DD90@dggemm513-mbs.china.huawei.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/dEJRtf7na7Jr6i2XyYNb9VtFehA>
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2021 15:51:16 -0000


> On 2 Mar 2021, at 14:21, Liguangpeng (Roc, Network Technology Laboratory) <liguangpeng@huawei.com> wrote:
> 
> Hi Stewart,
>  
> Backwards compatible should be always good thing for investment protection. Except “could put your new packet into a IPv6 parser”,

> another possible approach is the last new forwarder translate new packet to IPv6 packet (may encapsulate new fields in extension header), and passthrough in IPv6 domain.

> Then the first new forwarder adjacent to IPv6 forwarder must recognize IPv6 encapsulation and traversing all extension headers to form new packets if next hop is new forwarder.

If you could write down the two formats and describe the mappings that would make people reading this thread feel a lot more comfortable that this is feasible. It would also enable everyone to understand any limitations and constraints with the approach you propose.

- Stewart

> Guangpeng Li
>  
> From: Stewart Bryant [mailto:stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>] 
> Sent: Tuesday, March 2, 2021 9:53 PM
> To: Toerless Eckert <tte@cs.fau.de <mailto:tte@cs.fau.de>>
> Cc: Stewart Bryant <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>>; Jiayihao <jiayihao@huawei.com <mailto:jiayihao@huawei.com>>; draft-jia-scenarios-flexible-address-structure@ietf.org <mailto:draft-jia-scenarios-flexible-address-structure@ietf.org>; int-area <int-area@ietf.org <mailto:int-area@ietf.org>>; draft-jia-flex-ip-address-structure@ietf.org <mailto:draft-jia-flex-ip-address-structure@ietf.org>
> Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses
>  
>  
> 
> 
> On 1 Mar 2021, at 15:33, Toerless Eckert <tte@cs.fau.de <mailto:tte@cs.fau.de>> wrote:
>  
> I really don't understand why the IPv6 world has not understood how the most easy way
> to allow for the applicability of IPv6 to grow (especially beyond "just more addresses thn IPv4")
> would be to come up with a backward compatible encap on the wire that would support additional
> address lengths.
>  
> Toerless
>  
> I don’t think there is a simple backwards compatible approach, but we can probably do more than we do today.
>  
> Backwards compatible means that you could put your new packet into a IPv6 parser and it would correctly forward the packet as if nothing had changed.
>  
> You could I suppose put a well known IPv6 address in the IPv6 header and put the real address in an extension header, perhaps including the pointer to the address in the suffix of the IPv6 address to make finding the EH much faster, but I am not sure that is backwards compatible.
>  
> I suppose it might be able to do a bit better if the address in the IPv6 DA was the DA of the egress router and old routers did best effort to the egress and newer routers knew to take a look at the extension header for more detail.
>  
> I think that it is worth thinking about how we could do better than we do today, but I think we need to be careful with the term backwards compatible.
>  
> - Stewart