From nobody Tue Jul 27 13:04:28 2021 Return-Path: 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 82F743A0FFA; Tue, 27 Jul 2021 13:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 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=-0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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 TWx0U3Ahar_c; Tue, 27 Jul 2021 13:04:22 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 696C23A103E; Tue, 27 Jul 2021 13:04:22 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id k4-20020a17090a5144b02901731c776526so6360682pjm.4; Tue, 27 Jul 2021 13:04:22 -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=DWnoo4EyNpOCNxga/SvLwfsf0F1TpRZNDvRkmBPz4IQ=; b=Zq5994vX1PnlPgK4YGhpbbXrgWpEn3h2/KRwQae4rtKmwDzTxRFEspBAoGi5Gmrdod on0COK8ZcHRIsVzOWULI5dOZvi9noYn69l+CLINWcLD92VVqBH8a+nCpqiJno8CBB42m SMMV2lgngW18kUQe7T6GHjY47IyLU9YMZz9XfefgIOzgCAdj3LZ8iLz+7gzyZ7EB8VSZ mkEfNN3y2HFbS142NC0Bh/7C5b3CAeAjzBA85iy0dQGuO5WangWq/YQluZkuzOMcQcMA TXxzl3AbUxBIMxvODyvSsyviZtVJnE3wdpB8KWqBlkoe3rnzsmnC6g3RSY+ZrBhRB9pS lKrA== 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=DWnoo4EyNpOCNxga/SvLwfsf0F1TpRZNDvRkmBPz4IQ=; b=jI+H+zbFP2Qsyvnw39CwNKhjxzVTpR2bQkd/RVZq1wh69x0XxGnPWeSTcrt1zE91D0 OzJOfvPiWf3YIDh55DK2x/2RwiMM5MJx9lxP8uCz0zq3lpPY526sBjh11o53ULPEIyKH I052rA7lFReIQm5MMY8vOAySn1OqRUH+p/O2qvI/1RcGR7ZvV4kPTmuBws+m0kJVTM75 wGH+nTVmWY1GMdRApXTF8oAJNNIOPl72kteJ9qpARXZbXlAAp1QTH0WZ/WnbLBsVw9Ha Ixt8XGHtDzsOXELpunES+qCZOGfFo3G0KhTR6ON25H17pVKPE2Z7yQNJTepA2a//kN2U 6XNg== X-Gm-Message-State: AOAM532heH9Njx6EKknxOjcWNUL99sB+51D8Sqovqt4GEhB/tmUSfi12 7Jd2C0Z5jvQnOTKwakBIymiMh5tiaiv5mA== X-Google-Smtp-Source: ABdhPJydHhezc45bIH1ZdokFdGMRP4OKEKP2IgkUdJwdagd71/edBrM4qznj4Q3jKevZT2iKJKFPng== X-Received: by 2002:a17:902:e04f:b029:eb:66b0:6d08 with SMTP id x15-20020a170902e04fb02900eb66b06d08mr20027447plx.50.1627416261431; Tue, 27 Jul 2021 13:04:21 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id t6sm3601376pjo.4.2021.07.27.13.04.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 13:04:20 -0700 (PDT) Subject: Re: changes in draft-ietf-cbor-network-addresses-05.txt To: tom petch , Erik Kline , "cbor@ietf.org" Cc: 6MAN <6man@ietf.org> References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> From: Brian E Carpenter Message-ID: Date: Wed, 28 Jul 2021 08:04:16 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 20:04:28 -0000 On 26-Jul-21 23:49, tom petch wrote: > From: ipv6 on behalf of Brian E Carpenter > Sent: 25 July 2021 00:44 >=20 > There's an "interesting" issue there, especially for IPv6, which is tha= t the interface ID (or "zone index", per RFC4007) has no meaning outside = the host. So it really shouldn't need to be sent on the wire in normal ci= rcumstances. >=20 > (The conversation around RFC6874bis is slightly relevant.) >=20 > > Brian >=20 > As I may have said before, the YANG Types RFC6991 provides types for IP= v4 and IPv6 addresses both with a zone index. It also provides no-zone t= ypes with a suffix 'no-zone' on the type name. I see evidence that most = authors of YANG modules do not realise that a reference to 'ip-address' p= er se is a reference to the format that includes the zone and so have spe= cified that format in many if not most cases. Thus it seems likely that = many of the addresses on the wire are in the zone format, even if the zon= e is rarely present. With hindsight, it might have been better to have s= pecified 'ip-address' and 'ip-address-zone' rather than ip-address' and i= o-address-no-zone'. Makes sense. The reply I just sent to Christian Ams=C3=BCss probably appl= ies to YANG too. Sending a zone index to another host is rarely meaningfu= l or useful. Brian >=20 > Tom Petch >=20 > Regards > Brian Carpenter >=20 > On 25-Jul-21 10:42, Erik Kline wrote: >> Michael, >> >> Thanks for the update. >> >> Was there any interest in figuring out a representation for link-local=20 addresses (e.g. 169.254.x.y, fe80::zed, ff02::pqr, ...) that included eit= her an interface name or index as part of a structured unit? Perhaps som= e generic {address_info, interface_info} pairing that could be used the s= ame way? >> >> Obviously, it's possible to pair what you've described here together w= ith extra interface information separately on an ad hoc basis. >> >> Curious, >> -ek >> >> On Mon, Jul 12, 2021 at 4:41 AM Michael Richardson > wrote: >> >> >> internet-drafts@ietf.org wrote: >> >=C2=A0 Title : CBOR tags for IPv4 and IPv6 addresses a= nd prefixes >> > Authors : Michael Richardson Carsten Bormann >> > draft-ietf-cbor-network-addresses-05.txt Pages : 8 Date : 20= 21-07-12 >> >> > Abstract: This document describes two CBOR Tags to be used w= ith IPv4 >> > and IPv6 addresses and prefixes. >> >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-cbor-network-add= resses/ >> >> > There is also an HTML version available at: >> > https://www.ietf.org/archive/id/draft-ietf-cbor-network-addr= esses-05.html >> >> > A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-network-= addresses-05 >> >> The major differences since -04 is that we now have three forms: >> >> 1) IPv4 or IPv6 address. >> 2) IPv4-prefix/len or IPv6-prefix/len >> new: 3) IPv4-addr/len or IPv6-addr/len >> >> The difference between (2) and (3) is that (2) is just the prefix,=20 and the >> bits to the right MUST be zero, and MAY be omitted. (A bit win for=20 IPv6/32 or >> Ipv6/48s..). >> In the case of (3), this is more of an interface definition, like:= >> 2001:db8::1234/64 the "::1234" is to the right of the /64. >> 192.0.1.4/24 =C2=A0 ".4" is to the righ= t of the /24, and is the interface definition. >> >> Cases (2) and (3) are distinguished by order of data vs prefix. >> (2) is: [64, h'20010db8'] >> (3) is: [h'20010db8_00000000_00000000_00001234', 64] >> We can do this in CBOR, because it is self-describing. >> Note that (2) is much shorter than (3), because trailing zeroes ar= e > omitted. >> (3) is always 18 or 19 bytes long. (1 byte for CBOR array prefix) >> >> Prefix longer than 24 require two bytes to encode the integer. >> (I guess we could have made the prefixlen be length-24, and then u= p > to /48 >> would fit into a single byte integer. We could also have made > the negative >> integers represent multiples of -4 perhaps) >> >> I don't personally have a use case today for (3), but there were n= ot many >> objections to including it. >> >> -- >> Michael Richardson >=C2=A0 . o O ( IPv6 I=C3=B8T consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> ------------------------------------------------------------------= -- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 > >> ------------------------------------------------------------------= -- >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20