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

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Jun 2019 19:18:00 +0200

Hi 6MANners,

In private discussion we disagree about this point:

I maintain that 1111 1110 10 equals 0x3fa, because that's what my 
Windows Calculator says: I type 1111 1110 10 and it converts to 0x3fa.

On another hand, I am rhetorically asked how can 1111 1110 10 be 0x3fa?

(the 1111 1110 10 are the 10 leading bits of the IPv6 link local 
addresses, which is familiarly known to start with an fe80).

On my side, this is a difficulty to understand this 0xfe80, especially 
since 1111 1110 10 is so printed in Figure in RFC4291.

Alex

---

From: Bob Hinden <[email-masked]>
Date: Thu, 6 Jun 2019 10:44:58 -0700

> On Jun 6, 2019, at 10:18 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi 6MANners,
> 
> I maintain that 1111 1110 10 equals 0x3fa, because that's what my Windows Calculator says: I type 1111 1110 10 and it converts to 0x3fa.

The binary string 1111111010 is indeed 0x3FA.  A binary to hex calculator right justifies it, so it is converting 001111111010.

When used as a prefix it is 0xFE8.  In that case it is left justified.

Bob

> (the 1111 1110 10 are the 10 leading bits of the IPv6 link local addresses, which is familiarly known to start with an fe80).
> 
> On my side, this is a difficulty to understand this 0xfe80, especially since 1111 1110 10 is so printed in Figure in RFC4291.
> 
> Alex
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Thu, 6 Jun 2019 10:48:38 -0700

> On another hand, I am rhetorically asked how can 1111 1110 10 be 0x3fa?
Alexandre, presumably you're referring to the table in section 2.4. In
this context 1111 1110 10 is a binary prefix, not an ordinal number,
so it is neither equal to 0xf3a nor 0xfe80. It is equal to FE80::/10
in IPv6 notation as inidicated.

Tom

---

From: Sander Steffann <[email-masked]>
Date: Thu, 6 Jun 2019 20:46:28 +0200

Hi Alexandre,

> On my side, this is a difficulty to understand this 0xfe80, especially since 1111 1110 10 is so printed in Figure in RFC4291.

It's a prefix of an IPv6 address. IPv6 addresses are 128 bits long. Expand to 128 bits and try again :)

1111 1110 1000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 equals 0xfe800000000000000000000000000000. Not sure if Windows Calculator can handle that though…

Cheers,
Sander

---

From: Warren Kumari <[email-masked]>
Date: Thu, 6 Jun 2019 16:17:23 -0400

> 1111 1110 1000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 equals 0xfe80000000000000000000000000…

Windows calc probably can't, but:
$ echo 'print hex(0b1111111010 << (128-10))'  | python

or https://repl.it/repls/AwareDecentGeeklog if you don't have Python
(because windows :-p)

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Jun 2019 14:41:11 -0700

> I maintain that 1111 1110 10 equals 0x3fa, because that's what my Windows Calculator says: I type 1111 1110 10 and it converts to 0x3fa.

You're correct if those are the only bits. However, in 1111 1110 10 you have to also include 00 0000, because it's a /10 prefix. It's fe80::/10, not ten bits of information with the least significant bit in the "ones" location.
--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Jun 2019 07:50:14 +0200

Le 06/06/2019 à 23:41, Fred Baker a écrit :
> You're correct if those are the only bits. However, in 1111 1110 10
> you have to also include 00 0000, because it's a /10 prefix.

?

1111 1110 10 are 10 bits and they are the only bits.

I would indeed add the 00 0000 if they were 16bits, and then I would 
write fe80::/16.

But, since a few people say differently, I think I will need to look at 
it deeper.  MAybe it is just a matter of language expression.

Alex

  It's
> fe80::/10, not ten bits of information with the least significant bit
> in the "ones" location. 
The fact that there is a highway to hell and a stairway to heaven is an 
interesting comment on projected traffic volume...

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Jun 2019 07:55:19 +0200

> It's a prefix of an IPv6 address. IPv6 addresses are 128 bits long. Expand to 128 bits and try again :)

(I will try that twice on some other calculator that has 64bit operators.)

Is it wrong to write that 3fa::/10 is the link-local prefix?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Jun 2019 08:16:41 +0200

Le 06/06/2019 à 23:41, Fred Baker a écrit :
> you have to also include 00 0000, because it's a /10 prefix. It's

Sorry, I think there is an error in the Windwos Calculator.
When typing 10 bits in binary it automatically precedes them with two 0 
bits; presumably it is because it wants to have nibbles (groups of 4 
bits) such that to be able to convert in hex.  That makes it display 
0011 1111 1010 even though it is not that what I typed.  And so it 
converts it wrongly into 3fa.

On another hand, the binary value 1111 1110 10 converts into FE8 only if 
I add two 0 bits at the end (not before), like this: 1111 1110 1000. 
But I do not want to add two 0s at the end, because there are only 10 
bits in the LL prefix, not 12.

So I dont know how to write 1111 1110 10 in hexa.  I will look further.

Sorry if this is all known... I will reduce traffic now.

Alex

---

From: Karl Auer <[email-masked]>
Date: Fri, 07 Jun 2019 16:53:41 +1000

> So I dont know how to write 1111 1110 10 in hexa.  I will look

As long as you look at that bit sequence in isolation, rather than
seeing it as the beginning of a 128-bit sequence, you will keep having
the same problem. If you just want to represent the bit pattern
1111111010, then 0x3fa is fine. But if it is an IPv6 prefix, there are
rules and a standardised notation. If you are trying to represent an
IPv6 prefix you need to you need to add in the rest of the 128 binary
digits before compressing it into hexadecimal.

We have a notation for "the rest of the digits", it is "::". But the
notation also requires implicit or explicit zero padding to make up
complete sets of sixteen bits where those bits are between two colons
or between a colon and either end of the entire sequence. If the
padding is omitted, then leading zeros are implied for any value less
than 0x8000. If right-hand padding is needed you need to make it
explicit.

3fa::/10 would only be correct if the bit pattern was 0000001111111010,
i.e. if there were six actual zero bits at the start of the sequence.

1111111010 is only ten bits, so must be explicitly right-hand padded to
sixteen bits (1111111010000000), then get converted into hex (FE80),
then get "::" tacked on the end to represent the remaining zeros
(FE80::) then get a prefix length to show how many bits from the left
are significant (in this case 10, so FE80::/10).

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
Old fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Fri, 7 Jun 2019 08:58:33 +0200

Hi Alex,

> 1111 1110 10 are 10 bits and they are the only bits.

Gee, it's only binary arithmetic. We use a nibble-wise textual
representation with hex digits, so you have to fill it up to
a multiple of 4 bits, i.e., adding two bits to the right gives you
12 bits, which nicely converts to 0xfe8. If you want 0xfe80 you
need to add 00 0000 as Fred pointed out.

> it deeper.  MAybe it is just a matter of language expression.

Sorry, but fe80:: doesn't imply fe80::/16, that's exactly the reason
why we have the prefix notation. fe80::/10 means to expand to 128 bit
and then use the leftmost 10 bits only. That's unambiguous.

Regards
 Roland

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Jun 2019 10:53:28 -0700

> On Jun 6, 2019, at 10:55 PM, Alexandre Petrescu <[email-masked]> wrote:
> 

Which is to say that the bit pattern is 0000 0011 ffff 1010, and the prefix is the first ten bits (0000 0011 11) of that? If that's what you intend, no, it's not wrong. If you are thinking in terms of https://tools.ietf.org/html/rfc4291#section-2.5.6, there is no way that would work. It doesn't conform to https://tools.ietf.org/html/rfc4632 (which only uses IPv4 examples, but IPv6 works the same way).

Here's a simple way to think about this that might help you get your head around it. Let's imagine I have a prefix 2001:db8::/32, and I want to divide it into two 33 bit prefixes. What are they? 2001:db8:0000::/33 and 2001:db8:8000::/33, of course. It turns around the next bit.

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.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 16:59:49 +0200

> or https://repl.it/repls/AwareDecentGeeklog if you don't have Python

For sake of completeness, google puts '1111111010 in hex' as 0x423A3562.

qwant does not convert it.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 15 Jun 2019 17:02:55 +0200

> and then use the leftmost 10 bits only. That's unambiguous.

Sorry, it is ambiguos.

Even if you expand it to 128, you still need only the 10bits.  The 
expansion to 128 bits has no particular meaning.  Were the 128bit 
expansion meaning anything; then we would not need to convert.

Rather, probably a new base is needed for IPv6 (a base is like binary, 
hexa, octal, etc).

Alex

---

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Jun 2019 13:28:15 -0400

' i

> For sake of completeness, google puts '1111111010 in hex' as 0x423A3562.

Your point?
One billion, one hundred and eleven million, one hundred and eleven
thousand and ten is, in fact, 0x423A3562
In exactly the same way, if you enter '1+1' it gives you 2, and not 0b10.

Perhaps you actually meant "0b1111111010  to hex", which it correctly
converts to 0x3FA.

A number of people have (in my opinion very politely) suggested that
you spend some time reading up on subnetting. I'd second this
recommendation, and suggest "Internet Routing Architectures" by Sam
Halabi (http://www.ciscopress.com/store/internet-routing-architectures-9781578702336
) - while it was written in 2000, and is focused on IPv4, the concept
is *exactly* the same.

I suspect that, at this point, I'm simply being trolled --
unfortunately though, as the Operations AD I often have to counter the
accusation that the IETF is detached from operations and doesn't
understand how protocols we design are used -- this thread fully plays
into that.

W

---

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Jun 2019 14:23:22 -0400

> I suspect that, at this point, I'm simply being trolled --

Apologize - I lost my cool, accusing someone of trolling is not OK; I
apologize, it was wrong of me.

Sorry,
W

---

From: Sander Steffann <[email-masked]>
Date: Sat, 15 Jun 2019 20:34:24 +0200

Hi Warren,

> apologize, it was wrong of me.

Considering the contents and persistence of this discussion I don't blame you. I had the same thoughts...

Alexandre has been a long term participant, but making a problem of prefix notation that is unambiguous and well understood is currently very bad for the SNR on this list.

In short: I'm happy that someone spoke up. Maybe calling it trolling isn't the right way, but I've had enough of this thread...

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Jun 2019 10:46:03 +0200

Le 15/06/2019 à 19:28, Warren Kumari a écrit :
>>>>> I maintain that 1111 1110 10 equals 0x3fa, because that's
>>>>> what my Windows Calculator says: I type 1111 1110 10 and it
>>>>> converts to 0x3fa.
>>>>> 
>>>>> (the 1111 1110 10 are the 10 leading bits of the IPv6 link
>>>>> local addresses, which is familiarly known to start with an
>>>>> fe80).
>>>>> 
>>>>> On my side, this is a difficulty to understand this 0xfe80,
>>>>> especially since 1111 1110 10 is so printed in Figure in
>>>>> RFC4291.
>>>> 
>>>> It's a prefix of an IPv6 address. IPv6 addresses are 128 bits
>>>> long. Expand to 128 bits and try again :)
>>>> 
>>>> 1111 1110 1000 0000 0000 0000 0000 0000 0000 0000 0000 0000
>>>> 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
>>>> 0000 0000 0000 0000 0000 0000 0000 0000 equals
>>>> 0xfe800000000000000000000000000000. Not sure if Windows
>>>> Calculator can handle that though…
>>> 
>>> Windows calc probably can't, but: $ echo 'print hex(0b1111111010
>>> << (128-10))'  | python
>>> 
>>> or https://repl.it/repls/AwareDecentGeeklog if you don't have
>>> Python (because windows :-p)
>> 
> Your point? One billion, one hundred and eleven million, one hundred
> and eleven thousand and ten is, in fact, 0x423A3562 In exactly the
> same way, if you enter '1+1' it gives you 2, and not 0b10.
> 
> Perhaps you actually meant "0b1111111010  to hex", which it
> correctly converts to 0x3FA.

True, that was the error.

> Halabi
> (http://www.ciscopress.com/store/internet-routing-architectures-9781578702336
>
> 
> I suspect that, at this point, I'm simply being trolled -- 

I want to excuse to you and others if feeling trolled.  It is not my 
intention.

> unfortunately though, as the Operations AD I often have to counter
> the accusation that the IETF is detached from operations and doesn't 
> understand how protocols we design are used -- this thread fully
> plays into that.

I read it.

Alex

>>>> Cheers, Sander
>>>> [email-masked] Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6