RE: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Mon, 10 June 2019 17:47 UTC

Return-Path: <dmudric@avaya.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 8DF47120143 for <ipv6@ietfa.amsl.com>; Mon, 10 Jun 2019 10:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.91
X-Spam-Level:
X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=avaya365.onmicrosoft.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 AvJImXtRiXGy for <ipv6@ietfa.amsl.com>; Mon, 10 Jun 2019 10:47:32 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 BC406120089 for <ipv6@ietf.org>; Mon, 10 Jun 2019 10:47:31 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2EgAABTl/5c/wUHmMZmHQEBBQEHBQGBUQgBCwGBDi9QbXUEMwqEC4NHA4RSig2CV4lDjx2BJAMYFyAFCQEBAQ0BGAEJBwQCAQEChD4CF4JeIzQJDgEDAQEBBAEBAQEDAQICaRwMgnhNLwoCMAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDykMEgEBGAEBAQECAQEBEBEKEwEBLAsBBAsCAQgNBAMBAQEBJwMCAgIfBgsUCQgCBA4FCBqDAYEdTQMODwECAgqdGQKBCDCIXgEBcIExGgKCXQEBBYR+DQuCDwkJAYEqAYg/gx0XgUE+gRFGgh4uPoIaRwEBAgEXgUkFBwkJDQkIgkwygiaLXoJKdIN4iD6NGz4JAoIPhkSJE4QGgw6KBAOKBpQmgWONRAICAgIEBQIOAQEFgU85gVhwFTuCbAmCBoNwhRSFP3IBAQEBEYEUjWkBgSABAQ
X-IPAS-Result: A2EgAABTl/5c/wUHmMZmHQEBBQEHBQGBUQgBCwGBDi9QbXUEMwqEC4NHA4RSig2CV4lDjx2BJAMYFyAFCQEBAQ0BGAEJBwQCAQEChD4CF4JeIzQJDgEDAQEBBAEBAQEDAQICaRwMgnhNLwoCMAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCDykMEgEBGAEBAQECAQEBEBEKEwEBLAsBBAsCAQgNBAMBAQEBJwMCAgIfBgsUCQgCBA4FCBqDAYEdTQMODwECAgqdGQKBCDCIXgEBcIExGgKCXQEBBYR+DQuCDwkJAYEqAYg/gx0XgUE+gRFGgh4uPoIaRwEBAgEXgUkFBwkJDQkIgkwygiaLXoJKdIN4iD6NGz4JAoIPhkSJE4QGgw6KBAOKBpQmgWONRAICAgIEBQIOAQEFgU85gVhwFTuCbAmCBoNwhRSFP3IBAQEBEYEUjWkBgSABAQ
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Jun 2019 13:47:29 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2019 13:47:30 -0400
Received: from PW365VMAP02.avaya.com (135.8.98.110) by AZ-US1EXHC01.global.avaya.com (135.11.85.12) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 10 Jun 2019 13:47:28 -0400
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (104.47.50.55) by PW365VMAP02.avaya.com (135.8.98.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Mon, 10 Jun 2019 12:47:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Avaya365.onmicrosoft.com; s=selector1-Avaya365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jg1vBsKkkp3d2nKWsVQ4Jscj8jCm4+ZqrfEET1R+nhE=; b=o5BefqKqfiLfJzON0PHbi2vD4Xpzs/ihOuvr+vEXq4zwi3MExMM2Oe9/gfEwEaBjq+ZPEbvYDcJa3vDL6XLd7XhlS3+cT6158WcpiJGCYoIL76tFzm3RIDJWo3yP+OK5P/p3xiq5lwXYcJ5OpgcjlM2mqWuiZOaJp7wvxU/WqbQ=
Received: from DM6PR15MB2506.namprd15.prod.outlook.com (20.176.71.32) by DM6PR15MB2220.namprd15.prod.outlook.com (20.176.70.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.14; Mon, 10 Jun 2019 17:47:26 +0000
Received: from DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::fc26:4d7:b56:72ac]) by DM6PR15MB2506.namprd15.prod.outlook.com ([fe80::fc26:4d7:b56:72ac%7]) with mapi id 15.20.1965.017; Mon, 10 Jun 2019 17:47:26 +0000
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Yucel Guven <yucel.guven@gmail.com>
CC: Tom Herbert <tom@herbertland.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?
Thread-Topic: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?
Thread-Index: AQHVH7Pp+gNZh4vda0yis3TC+5PuZaaVJxxQ
Date: Mon, 10 Jun 2019 17:47:26 +0000
Message-ID: <DM6PR15MB2506500812BD78F68E0480E2BB130@DM6PR15MB2506.namprd15.prod.outlook.com>
References: <DM6PR15MB2506E62560613C85F74A1FF8BB100@DM6PR15MB2506.namprd15.prod.outlook.com> <CALx6S36vVpD9bAPSBQmhV+daR0Yr4heQ-LaiB4hABAs8ofVfNQ@mail.gmail.com> <DM6PR15MB25063BAF058C1825E2B63E30BB130@DM6PR15MB2506.namprd15.prod.outlook.com> <CAKQ4NaW-QRZDO52zDZTSqz_MsfrS1uQHdz6zFjo+gXvtYVnFxA@mail.gmail.com> <DM6PR15MB2506E06165EA22E66BBB9524BB130@DM6PR15MB2506.namprd15.prod.outlook.com> <CAKQ4NaX=ydmGC9L8-qbt_Dv9X+Ldp9ev+vLfHX17vt_6hpoDow@mail.gmail.com>
In-Reply-To: <CAKQ4NaX=ydmGC9L8-qbt_Dv9X+Ldp9ev+vLfHX17vt_6hpoDow@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dmudric@avaya.com;
x-originating-ip: [104.129.196.166]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d36f6f5c-3fc7-4ed9-47c6-08d6edcbb3a1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2220;
x-ms-traffictypediagnostic: DM6PR15MB2220:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <DM6PR15MB2220956BA4DFF1DC29303D03BB130@DM6PR15MB2220.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0064B3273C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(136003)(366004)(346002)(189003)(43544003)(199004)(606006)(316002)(99286004)(966005)(14454004)(81166006)(6246003)(33656002)(53936002)(478600001)(74316002)(52536014)(236005)(6306002)(54896002)(86362001)(9686003)(2906002)(55016002)(81156014)(229853002)(54906003)(8676002)(71190400001)(6436002)(7736002)(486006)(476003)(71200400001)(8936002)(186003)(66066001)(26005)(66946007)(66556008)(66476007)(66446008)(25786009)(68736007)(76116006)(64756008)(76176011)(790700001)(55236004)(53546011)(6506007)(4326008)(73956011)(446003)(11346002)(5660300002)(6916009)(6116002)(256004)(7696005)(3846002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2220; H:DM6PR15MB2506.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: avaya.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Ar3nQJ7JK2I4SGxGatOVc+YP2qnZqJniP5sA9OBZUPPLsE2s6WQ+GXqgoJghOhZIOtnYPL1PtlzVDxC3wRjI7r+c2xGD6gNBeSeo9Q3Zmm10Portphfa70moqeFP94XTQaOLAX/TI82mhfYvSkZKj1fj9efNIXuLsH0wyyXbHrdjLFiVb8uKpCtsPazIVtSyj+CEqTlWbXPkPbO9uyv97W4qYvmLpO7h1yW5/6ffnK2fuMboe6XqzvA5EbLGB2WET3tczrqp5puXN+acxCZXViNpXkE4mz/hn+XESSD3BukLQ10VUIdVigVGcEgJmbJyPe93Cjjxtuz1l724S7aI9VWAjSdn0N865D8Mb4g3WdqeimS2TGKE5hVX11Gf5WgFHBP1uIFdiUZxjqWBqnTxHpAoqPXPVVavu8p0BBw9y3o=
Content-Type: multipart/alternative; boundary="_000_DM6PR15MB2506500812BD78F68E0480E2BB130DM6PR15MB2506namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d36f6f5c-3fc7-4ed9-47c6-08d6edcbb3a1
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2019 17:47:26.5400 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 04a2636c-326d-48ff-93f8-709875bd3aa9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dmudric@avaya.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2220
X-OriginatorOrg: avaya.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/U-WtzC75qPqTCA7qoOhiaMddBVs>
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: Mon, 10 Jun 2019 17:47:36 -0000


From: Yucel Guven <yucel.guven@gmail.com>
Sent: Monday, June 10, 2019 1:43 PM
To: Mudric, Dusan (Dusan) <dmudric@avaya.com>
Cc: Tom Herbert <tom@herbertland.com>; ipv6@ietf.org
Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?

RFC 4291 sec.2.5.6  does NOT define a range. 10 bits are fixed, 54 bits are zero, and the remaining 64 bits are for interface ID, that's all.
[Dusan] RFC 4291 section 2.5.6 clearly defines the LL prefix value. If there is no comment that 54 bits following 10 bit LL identifier are zeros, like in section 2.4, which RFC defines the meaning on FE80::/10? Can FE80::/10 stand on its own and be clearly interpreted based on the existing RFCs?

The topic of this thread/chain is: "Is 1111 1110 10 equal to 0xfe80 or 0x3fa?"
If you want to make comparison, you must take care of all 128 bits of the 0xfe80,
but not only a part of it.
In fact it should be written as '0xfe800000000000000000000000000000'
because it's a one complete number.

1111: this is 'f'
1110: this is 'e'
10??: Why do you take only two bits? Your answer will be: "Because it's /10".

That approach is not true when you convert the number back to hexadecimal notation.
You MUST think/care of ALL the 128bits, not only a part of it,
otherwise you destroy/change the original number.

Reg.'s
Yucel

On Mon, Jun 10, 2019 at 6:09 PM Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:


From: Yucel Guven <yucel.guven@gmail.com<mailto:yucel.guven@gmail.com>>
Sent: Monday, June 10, 2019 12:47 PM
To: Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>>
Cc: Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>>; ipv6@ietf.org<mailto:ipv6@ietf.org>
Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?

No need to define as a range.
When you specify the prefix-length, it already defines a range.
e.g. FE80::/10 (absolutely not  FE8::/10)  has the range of
fe80:0000:0000:0000::/10 - febf:ffff:ffff:ffff::/10
[Dusan] I agree that FE80::/10 is the FE80::/10 – FEBF::/10 range. However, it is not define like a range in RFC 4291 and if often misinterpreted as just one value of FE80:0000:0000:0000. The question is how to write it to make it clear this definition is a range?

https://tools.ietf.org/html/rfc4291#section-2.5.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4291-23section-2D2.5.6&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Dm0yrColGfouwgn9pkesvO1Cps-EFn409_tRHPcKjGY&s=BbJ9ig6nTgOxyAm2iyQJBmjoBuKDC38eSMUunZJngbQ&e=> defines LL as the address with 64 bit FE80:0000:0000:0000 prefix, not as the fe80:0000:0000:0000::/10 - febf:ffff:ffff:ffff::/10 range. There are applications that need more flexibility for the LL prefix, like draft-petrescu-6man-ll-prefix-len. For these applications, FE80::/10 would be defined as LL identifier, not a prefix. The LL prefix would start with LL identifier and can have a variable length.

Is there any strong reason to keep 54 bits of zeros in this definition, other than backward compatibility?
   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+


Reg.'s
Yucel

On Mon, Jun 10, 2019 at 3:58 PM Mudric, Dusan (Dusan) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:
> On Friday, June 7, 2019 at 3:48 PM Tom Herbert
> <tom@herbertland.com<mailto:tom@herbertland.com>> wrote
> >
> > >
> > > Message: 3
> > > Date: Fri, 7 Jun 2019 10:53:28 -0700
> > > From: Fred Baker <fredbaker.ietf@gmail.com<mailto:fredbaker.ietf@gmail.com>>
> > > To: Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>>
> > > Cc: IPv6 <ipv6@ietf.org<mailto:ipv6@ietf.org>>
> > > Subject: Re: Is 1111 1110 10 equal to 0xfe80 or 0x3fa?
> > > Message-ID: <A722E202-7671-4111-BA92-8A67B3D3B924@gmail.com<mailto:A722E202-7671-4111-BA92-8A67B3D3B924@gmail.com>>
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > >
> > >
> > > If I have prefix fe80::/10, as described in RFC 4291, the next bit
> > > is bit 11. Doing the same subdivision of the prefix is fe80::/11 and
> fea0::/11.
> > [Dusan] The hexadecimal definition for LL address is not syntactically
> correct. The binary 10 bit prefix 1111111010 cannot be presented as
> hexadecimal FE80::/10. It is rather a range FE80::/10 - FEBF::/10. In this
> notation, FE80::/10 = FEBF::/10,  because the first 10 bits are equal and other
> 6 should be ignored. 111 1111010 can be defined as FE80::/10 only if every
> time it is also mentioned that the trailing 6 bits are all zero.
>
> By that logic, we'd have to mention that the trailing 118 bits are zero.  E.g.
> FE80::/10 == FEBD:F676:BBBB:C654:FEBD:F676:BBBB:C654/10
> also. It's obviously convenient canonical notication to express all the trailing
> bits as zeroes for a prefix, but not required. For instance, ifconfig shows my
> host address as fe80::ac2f:ea58:94a:438/64 which in one string indicates both
> a fully qualified address and it's prefix bits.
[Dusan] In this example fe80::ac2f:ea58:94a:438/64 is LL address with 0xfe80 0x0000 0x0000 0x0000 prefix. Based on LL prefix definition, this LL address can have a value of feab::ac2f:ea58:94a:438/64 and still have the binary 10 bit prefix 1111111010

May be LL address can be defined in hex notation as a range FE8::/10 - FEB::/10? This range always has the same well know LL identifier, the binary 10 bit prefix 1111111010.

>
> Tom
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=BRDXJNikWmU_24IGmmgxydVbBKn0npUsCUzJlQGjN50&s=KXz9utU1mhnWkWv2-Qq1lkcJ-zsSoTl5OlPaaUOPd-Y&e=>
--------------------------------------------------------------------