Subject: [v6ops] IPmix version 01 modification.

From: Khaled Omar <[email-masked]>
Date: Thu, 15 Nov 2018 04:02:56 +0000

Hi,

Can you check the attached modification, almost no changes will be accomplished to the host, the IPv4 packet will remain the same, your comments will be appreciated.

Khaled

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Nov 2018 21:29:19 -0800

Not on this list.

> On Nov 14, 2018, at 8:02 PM, Khaled Omar <[email-masked]> wrote:
> 
> Hi,
> 
> <draft-omar-ipmix-01.txt>_______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Khaled Omar <[email-masked]>
Date: Thu, 15 Nov 2018 08:57:25 +0000

So where? :-)

Best Regards
Khaled Omar

________________________________
From: Fred Baker <[email-masked]>
Sent: Thursday, November 15, 2018 7:29:19 AM
To: Khaled Omar
Cc: [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

Not on this list.

---

From: Simon Hobson <[email-masked]>
Date: Thu, 15 Nov 2018 12:30:38 +0000

> Can you check the attached modification, almost no changes will be accomplished to the host, the IPv4 packet will remain the same, your comments will be appreciated.

This will be my one and only comment on this idea ...

The IPv4 to IPv6 translation cannot work in the general case. You are "somehow" expecting to encode 128 bits of address into 7 bits - without loss. That means the entire range of IPv6 accessible to the host is no more than 128 different addresses - which just isn't going to work. Even in a small business I've worked with networks with more nodes than that ! You can "steal" bits from the port number, but it's still not going to give you much.

And to get that 7 bit value, you'd need to use a lookup table* to track the mappings, and somehow track when they were last used - you'll need to retire old mappings to make space for new ones. So you'll need VERY close coupling between DNS and routers - the DNS will need to give out the same mapping that the router uses. And what happens when the host is "fairly busy", a mapping gets retired, then the host tries to use it again - the packets will go to the wrong IPv6 address and a connection is broken.
Just the DNS-router coupling means that it cannot work in the general case - it would prevent anyone using anything but the DNS server/resolver built into the router.

Do you not think that many people have tried to come up with some form of "IPv4 + extra bits" schemes without breaking everything ? No-one has since any method of adding extra address bits means changes to the protocol, network stacks, and applications - so it makes no more sense than taking the opportunity to fix other things while going to a much bigger address range that hopefully should last us for a very long time.

Of the four combinations (IPv4/6 source & IPv4/6 destination), 3 are already catered for :
4-4 is already in place, and can be tunnelled if a network drops IPv4 transit support
6-6 is what people are working on and subject to network support is really a solved problem - and tunnels are available to work around ISPs like my own who still don't have support for native IPv6.
6-4 is already there as there's already a documented way to encode IPv4 addresses in IPv6 addresses and a gateway (much like an existing IPv4 NAT gateway) could handle translation).
So that only leaves 4-6 which I've already pointed out cannot be solved by your idea.

IMO, the whole idea is a non starter and I'll make no more comment on it.

* There is no generic function that can map *ANY* IPv6 address into a 7 bit field without either loss or collision. So the only way to do it is to hold a list of discrete mappings and update them as the host attempts to communicate with different destination addresses. If you think you have found a lossless compression algorithm to compress 128 bits into 7 bits without any restrictions then patent it and you can make a lot of money from it !

---

From: Khaled Omar <[email-masked]>
Date: Thu, 15 Nov 2018 13:12:10 +0000

> The IPv4 to IPv6 translation cannot work in the general case. You are "somehow" expecting to encode 128 bits of address into 7 bits - without loss.

We can divide the IPv6 address into 4 blocks (32-bits each), meaning we will encode 32-bits into 5 bits, and the whole IPv6 address into 20 bits, I'm looking somewhere for a lossless compression (encoding) algorithm that encodes 2^5 bits into 5 bits.

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Thursday, November 15, 2018 2:31 PM
To: [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Gert Doering <[email-masked]>
Date: Thu, 15 Nov 2018 14:16:09 +0100

Hi,

> We can divide the IPv6 address into 4 blocks (32-bits each), meaning we will encode 32-bits into 5 bits, and the whole IPv6 address into 20 bits, I'm looking somewhere for a lossless compression (e…

Have fun, and report back when you found that algorithm.

I would love to be able to losslessly compress all my data into 5 bits.

(If you can compress 2^5 to 5 once, you can do that with the resulting 
bits again, and again, and again)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Simon Hobson <[email-masked]>
Date: Thu, 15 Nov 2018 13:26:49 +0000

Khaled Omar <[email-masked]> wrote:

> We can divide the IPv6 address into 4 blocks (32-bits each), meaning we will encode 32-bits into 5 bits

No you can't. A 32 bit value needs 32 bits to store it - otherwise you are losing data. Alternatively, you have to take a subset of the possible values and use a dynamic lookup table.

> and the whole IPv6 address into 20 bits, I'm looking somewhere for a lossless compression (encoding) algorithm that encodes 2^5 bits into 5 bits.

No, you're looking for a lossless compression algorithm to compress 128 bits into 7 bits. When you invent it, as I said, patent it fast and you'll be very very rich !
You are getting confused between "32 bits" which can store 2^32 different values and the number "32". With 5 bits you can encode any integer between 0 and 31 (using standard binary), or any 32 values if you use an algorithm or lookup table - you cannot encode any arbitrary element from the 4+ billion (2^32) numbers that can be represented in 32 bits.

Come back when you've figured that out.

---

From: Khaled Omar <[email-masked]>
Date: Thu, 15 Nov 2018 13:48:50 +0000

> You are getting confused between "32 bits" which can store 2^32 different values and the number "32".

Who said that, "encoders" compresses the 2^n-bits input into n-bits output, for small encoders, if n=3, that encoder can compress 8-bits input into 3-bits output, does this means that only 3-bits can represent 256-different value, no, but, 8-bits can be compressed into 3-bits. 

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Simon Hobson
Sent: Thursday, November 15, 2018 3:27 PM
To: [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

Khaled Omar <[email-masked]> wrote:

---

From: Simon Hobson <[email-masked]>
Date: Thu, 15 Nov 2018 14:06:05 +0000

> Who said that, "encoders" compresses the 2^n-bits input into n-bits output, for small encoders, if n=3, that encoder can compress 8-bits input into 3-bits output, does this means that only 3-bits c…

You are sort-of half right - but not seeing where the problem lies.
The problem you have is that however you do it, the 3 bits output can only represent 8 different values. Since the input 8 bits can represent 256 values, there are 248 input values that cannot be represented in the output. Since you cannot (for the application you are suggesting) ignore those values, then your idea simply will not allow the IPv4 host to access much of the IPv6 address space. At the very most it will have access to 128 (2^7) discrete IPv6 addresses - which is not much of the internet !

Since the host may require to connect with any address in a range that (at the moment) spans something like 112 bits* (give or take a bit or two), you are a very long way from allowing access to "the IPv6 internet".

* IIRC the global address pool is currently allocated out of the 2003:: block. However it's sparsely done and broken up by region, then registry, then ISP. So you can't simply say that you'll ignore everything above (say) 2003:0:1:: and reduce the number of input bits.

As already said, come back with an algorithm that will losslessly allow ANY arbitrary 128 bit values (both arbitrary values and arbitrary quantity of values) to be encoded in 7 bits and you might get a response other than "cannot work". A lookup table would work for up to 128 values, but breaks for 129 or more, and would also need lots of integration between DNS and router, plus processing ability for managing it and storage (128off 128bit values times however many IPv4 hosts you want to support).

Having hit NAT session table size/CPU issues in the past, I can tell you that such a lookup table method is certainly not without it's issues.

The idea is a non-starter.

---

From: Silvia Hagen <[email-masked]>
Date: Thu, 15 Nov 2018 14:08:45 +0000

I admire you guys....

:-)

---

From: Khaled Omar <[email-masked]>
Date: Thu, 15 Nov 2018 14:38:20 +0000

Check out the attached images.

---

From: Khaled Omar <[email-masked]>
Date: Thu, 15 Nov 2018 14:48:52 +0000

Please ignore the last e-mail.

---

From: Khaled Omar <[email-masked]>
Date: Sat, 17 Nov 2018 14:02:00 +0000

> The problem you have is that however you do it, the 3 bits output can only represent 8 different values. Since the input 8 bits can represent 256 values, there are 248 input values that cannot be r…

Check this out.

Khaled

---

From: Simon Hobson <[email-masked]>
Date: Sat, 17 Nov 2018 22:00:20 +0000

> Check this out.

OK, you'll have to explain what on earth it's supposed to be. What it definitely isn't is a means of compressing 32 bits down to 5 bits without loss.

---

From: Khaled Omar <[email-masked]>
Date: Sat, 17 Nov 2018 22:24:40 +0000

The input of the algorithm is 32-binary bits and can be extended to mor eeeee than that, one case is that the output is 5-binary bits with different output voltages, 0 can be represented in 10 different voltages and 1 can be represented in 10 different voltages, that means the output can represent 20^5 different values which covers the 2^32, the input can be decoded from the 5-bits easily using the table using only the 32 bits and not all the 35 bits.

Khaled
________________________________
From: v6ops <[email-masked]> on behalf of Simon Hobson <[email-masked]>
Sent: Sunday, November 18, 2018 12:00:20 AM
To: [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

---

From: Simon Hobson <[email-masked]>
Date: Sat, 17 Nov 2018 22:38:50 +0000

Khaled Omar <[email-masked]> wrote:
> 
> The input of the algorithm is 32-binary bits and can be extended to mor eeeee than that, one case is that the output is 5-binary bits with different output voltages

Then they are **NOT** bits. That's very fundamental stuff, and if you don't grasp basics like that then I suggest you stay away from trying to design complex protocols !

See https://en.wikipedia.org/wiki/Bit

---

From: Khaled Omar <[email-masked]>
Date: Sat, 17 Nov 2018 22:44:52 +0000

simon,

The 0-bit still a 0-bit, and the 1-bit still a 1-bit, no contradiction between this and the link you suggested.

Khaled
________________________________
From: v6ops <[email-masked]> on behalf of Simon Hobson <[email-masked]>
Sent: Sunday, November 18, 2018 12:38:50 AM
To: [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

---

From: Simon Hobson <[email-masked]>
Date: Sat, 17 Nov 2018 23:52:26 +0000

> The 0-bit still a 0-bit, and the 1-bit still a 1-bit, no contradiction between this and the link you suggested.

So tell me - when fed a "0" bit, which "0" is the expander expected to use ? For a bit, there are only two states - not 10 shades of off and 10 shades of on - but just off or on, or "0" or "1". So 5 of such bits can store precisely 32 different values - no more, no less.

You are clearly either really really ignorant of simple fundamental basics, or a complete troll - or both !

---

From: Khaled Omar <[email-masked]>
Date: Sun, 18 Nov 2018 00:22:07 +0000

Look, electronically, what is 0 and what is 1, 0 is 0 voltage, and 1 is 5 voltage, below 5 voltage is 0, 5 or over voltage is 1, so the values of voltages that can represent a 0 are listed on the file 0, 0.1, 0.2, etc and the values of voltages that can represent a 1 are 5, 5.1, 5.2, etc, so the 32 bits can be represented by 5 bits.

For example, the output can be 00000 for many number of inputs, and each 00000 has a different value of voltage that represents each 0.

Now it is very clear, looking forward for more discussions anywhere.

Khaled
________________________________
From: v6ops <[email-masked]> on behalf of Simon Hobson <[email-masked]>
Sent: Sunday, November 18, 2018 1:52:26 AM
To: [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

---

From: Khaled Omar <[email-masked]>
Date: Sun, 18 Nov 2018 00:46:37 +0000

Regarding using the word "troll", it shouldn't be used in any discussion because it reflects a bad image about the person who uses it, basics of respect.

Khaled

---

From: Gert Doering <[email-masked]>
Date: Sun, 18 Nov 2018 11:00:20 +0100

Hi,

> Regarding using the word "troll", it shouldn't be used in any discussion because it reflects a bad image about the person who uses it, basics of respect.

Troll level: archwizard.

Gert Doering
        -- NetMaster

---

From: Khaled Omar <[email-masked]>
Date: Sun, 18 Nov 2018 10:14:44 +0000

More accurate description, anway we can compress 32bits into 5bits (requires hardware changes), so when IPv6 can be represented in (20)bits, we can use nat46/dns46.
________________________________
From: Gert Doering <[email-masked]>
Sent: Sunday, November 18, 2018 12:00:20 PM
To: Khaled Omar
Cc: [email-masked]; Simon Hobson
Subject: Re: [v6ops] IPmix version 01 modification.

Hi,

Troll level: archwizard.

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Sun, 18 Nov 2018 21:39:07 +1100

Please respect the working group charter.

Your work may have value, however it isn't relevant here.

Thanks,
Mark.

On Sun., 18 Nov. 2018, 21:15 Khaled Omar <[email-masked] wrote:

> More accurate description, anway we can compress 32bits into 5bits
> (requires hardware changes), so when IPv6 can be represented in (20)bits,
> we can use nat46/dns46.
> ------------------------------
> *From:* Gert Doering <[email-masked]>
> *Sent:* Sunday, November 18, 2018 12:00:20 PM
> *To:* Khaled Omar
> *Cc:* [email-masked]; Simon Hobson
> *Subject:* Re: [v6ops] IPmix version 01 modification.
>
> Hi,
>
> > Regarding using the word "troll", it shouldn't be used in any discussion
> because it reflects a bad image about the person who uses it, basics of
> respect.
>
> Troll level: archwizard.
>
> Gert Doering
>         -- NetMaster
> --

---

From: Khaled Omar <[email-masked]>
Date: Sun, 18 Nov 2018 10:55:20 +0000

I do respect the charter, it contradicts with what people says here about what i'm doing.

Khaled
________________________________
From: Mark Smith <[email-masked]>
Sent: Sunday, November 18, 2018 12:39:07 PM
To: Khaled Omar
Cc: Gert Doering; Simon Hobson; [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

Thanks,
Mark.

On Sun., 18 Nov. 2018, 21:15 Khaled Omar <[email-masked]<mailto:[email-masked]> wrote:
More accurate description, anway we can compress 32bits into 5bits (requires hardware changes), so when IPv6 can be represented in (20)bits, we can use nat46/dns46.
________________________________
From: Gert Doering <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, November 18, 2018 12:00:20 PM
To: Khaled Omar
Cc: [email-masked]<mailto:[email-masked]>; Simon Hobson
Subject: Re: [v6ops] IPmix version 01 modification.

Hi,

Troll level: archwizard.

Gert Doering
        -- NetMaster

[email-masked]<mailto:[email-masked]>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 18 Nov 2018 11:04:45 +0000

Khaled Omar wrote on 18/11/2018 00:22:
> Look, electronically, what is 0 and what is 1, 0 is 0 voltage, and 1 is 
> 5 voltage, below 5 voltage is 0, 5 or over voltage is 1, so the values 
> of voltages that can represent a 0 are listed on the file 0, 0.1, 0.2, 
> etc and the values of voltages that can represent a 1 are 5, 5.1, 5.2, 
> etc, so the 32 bits can be represented by 5 bits.
> 
> For example, the output can be 00000 for many number of inputs, and each 
> 00000 has a different value of voltage that represents each 0.
> 

Right, I see what you're proposing: fractional voltage to encode 
multiple intermediate values between 0 and 1.  Nice!

Could I make a helpful suggestion?  It would probably be easier if you 
could write an internet draft to encode fractional ipv4 addresses.  So 
instead of having just 192.168.1.0 and 192.168.1.1, you could have a 
range of values in-between, e.g. 192.168.1.(1/2) or 192.168.1.(7/13). 
You'd need to work on the notation a bit because we're already using "/" 
to denote netmask, but I think the idea is sound, and it would solve a 
lot of problems with ipv4 deployment as well as providing a foundation 
for full ipv4 / ipv6 interoperability.  I.e. you'd solve two problems at 
once.

It would be a lot easier to handle this fractional idea at a higher 
level rather than trying to encode it at the electrical signaling level 
(see RFC 1925, Section 6).  The reason for this is that you'd probably 
need to make some changes at the electrical interface layer on IP 
routers to allow your signaling differentiation idea to work, and that 
could present some logistical problems.  Also, if you could make your 
proposal more generic by allowing floating point ipv4 addressing, that 
would probably be an advantage, but I don't think it would be necessary 
to go this far.  Fractional would be more than enough.

Nick

---

From: Khaled Omar <[email-masked]>
Date: Sun, 18 Nov 2018 11:58:59 +0000

Sounds interesting, it looks like a work that requires free time.

Thanks,

Khaled

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Sunday, November 18, 2018 1:05 PM
To: Khaled Omar <[email-masked]>
Cc: [email-masked]; Simon Hobson <[email-masked]>
Subject: Re: [v6ops] IPmix version 01 modification.

> Now it is very clear, looking forward for more discussions anywhere.

Right, I see what you're proposing: fractional voltage to encode multiple intermediate values between 0 and 1.  Nice!

Could I make a helpful suggestion?  It would probably be easier if you could write an internet draft to encode fractional ipv4 addresses.  So instead of having just 192.168.1.0 and 192.168.1.1, you could have a range of values in-between, e.g. 192.168.1.(1/2) or 192.168.1.(7/13). 
You'd need to work on the notation a bit because we're already using "/" 
to denote netmask, but I think the idea is sound, and it would solve a lot of problems with ipv4 deployment as well as providing a foundation for full ipv4 / ipv6 interoperability.  I.e. you'd solve two problems at once.

It would be a lot easier to handle this fractional idea at a higher level rather than trying to encode it at the electrical signaling level (see RFC 1925, Section 6).  The reason for this is that you'd probably need to make some changes at the electrical interface layer on IP routers to allow your signaling differentiation idea to work, and that could present some logistical problems.  Also, if you could make your proposal more generic by allowing floating point ipv4 addressing, that would probably be an advantage, but I don't think it would be necessary to go this far.  Fractional would be more than enough.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sun, 18 Nov 2018 23:29:12 +1100

You are not respecting the charter. Others responding to you aren't either.

On Sun., 18 Nov. 2018, 21:55 Khaled Omar <[email-masked] wrote:

> *From:* Mark Smith <[email-masked]>
> *Sent:* Sunday, November 18, 2018 12:39:07 PM
> *To:* Khaled Omar
> *Cc:* Gert Doering; Simon Hobson; [email-masked]
>> > Regarding using the word "troll", it shouldn't be used in any
>> discussion because it reflects a bad image about the person who uses it,
>> basics of respect.
>>
>> Troll level: archwizard.
>>
>> Gert Doering
>>         -- NetMaster
>> --

---

From: Simon Hobson <[email-masked]>
Date: Sun, 18 Nov 2018 14:04:31 +0000

> Look, electronically, what is 0 and what is 1, 0 is 0 voltage, and 1 is 5 voltage, below 5 voltage is 0, 5 or over voltage is 1, so the values of voltages that can represent a 0 are listed on the f…

Apart from your selection of voltages being very error prone, such encoding methods already exist in things like high speed modems and digital TV broadcasting - that screeching as a 56k modem connects is testing the connection to see which analogue levels get passed through reliably and selecing the encoding table to use only the unique ones). However, not a single ethernet port on the planet could deal with it (the signalling is based on transitions between states rather than voltages), and not a single router anywhere could pass the information through.
Realistically, all you are proposing is to replace ethernet with something with multiple levels per symbol - but internally all the digital handling would still need the full non-compressed bits because digital systems still work with digital bits.

But I think that you know all this this and are just trolling. I will not be commenting further and the way you're going you'll end up in a few killfiles.

---

From: Khaled Omar <[email-masked]>
Date: Sun, 18 Nov 2018 14:38:02 +0000

> Apart from your selection of voltages being very error prone, such encoding methods already exist in things like high speed modems and digital TV broadcasting - that screeching as a 56k modem connects is testing the connection to see which analogue levels get passed through reliably and selecting the encoding table to use only the unique ones). However, not a single ethernet port on the planet could deal with it (the signalling is based on transitions between states rather than voltages), and not a single router anywhere could pass the information through.

> Realistically, all you are proposing is to replace ethernet with something with multiple levels per symbol - but internally all the digital handling would still need the full non-compressed bits be…

You didn't add something new, I mentioned that this way of encoding requires hardware changes that need to be standardized.

Again, the information still represented in digital bits, but the one bit can hold different values that can be interpreted differently.

> But I think that you know all this this and are just trolling. I will not be commenting further and the way you're going you'll end up in a few killfiles.

Not the first time you try to threaten by not commenting further, it is me who will not respond back to you because you will make me use the word troll for describing you, be careful because your head started to touch the ground.

---

From: Olivier MJ Crépin-Leblond <[email-masked]>
Date: Mon, 19 Nov 2018 13:02:52 +0100

On 18/11/2018 01:22, Khaled Omar wrote:
> Look, electronically, what is 0 and what is 1, 0 is 0 voltage, and 1
> is 5 voltage, below 5 voltage is 0, 5 or over voltage is 1, so the
> values of voltages that can represent a 0 are listed on the file 0,
> 0.1, 0.2, etc and the values of voltages that can represent a 1 are 5,
> 5.1, 5.2, etc, so the 32 bits can be represented by 5 bits.
>
> For example, the output can be 00000 for many number of inputs, and
> each 00000 has a different value of voltage that represents each 0.
>

Congratulations, you've just invented a digital to analogue converter.
The problem is that these have been around for a long time. The other
problem is that the type of encoding you're speaking about is similar to
analogue TV signals like composite video etc. You immediately run into
problems of phase, interference between the different signals as well as
tolerance issues such as thermal and age tolerance - resistors and
capacitors that change tolerance over time. That's without taking into
account the Nyquist-Shannon sampling theorem and resulting Aliasing
especially at higher frequencies.

It's basically a non starter.

Kindest regards,

Olivier

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: Khaled Omar <[email-masked]>
Date: Mon, 19 Nov 2018 12:52:59 +0000

Why you call it analogue, still digital but with different limited amplitudes of voltages that still representing the 0 and 1 that should be interpreted successfully to computer systems, the issue for now is a matter of priority, what should be developed first, it shouldn't be without standardization, the challenge is in the amount of information that can be held by eevery 1 and every 0.

Khaled
________________________________
From: Olivier MJ Crépin-Leblond <[email-masked]>
Sent: Monday, November 19, 2018 2:02:52 PM
To: Khaled Omar; [email-masked]; Simon Hobson
Subject: [v6ops] IPmix version 01 modification.

Congratulations, you've just invented a digital to analogue converter. The problem is that these have been around for a long time. The other problem is that the type of encoding you're speaking about is similar to analogue TV signals like composite video etc. You immediately run into problems of phase, interference between the different signals as well as tolerance issues such as thermal and age tolerance - resistors and capacitors that change tolerance over time. That's without taking into account the Nyquist-Shannon sampling theorem and resulting Aliasing especially at higher frequencies.

Kindest regards,

Olivier

---

From: Khaled Omar <[email-masked]>
Date: Mon, 19 Nov 2018 18:21:32 +0000

There are many issues here that needs some focusing then we can move to the main issue that has relevance to the WG charter, no.1 is the name of the new signal, we can't call it analogue just because it has different values, but we can call it digital because it encodes a digital stream into a new digital stream with limited values, no.2 the amount of information carried (I.e. what is the standard track that determines how many bits can be eencoded on every one output), no.3 compressing normal binary bits to compress 32 bits in 5 bits (so this will help in many things including compressing an IPv6 address to be 20 bits or increasing the IPv4 address space using fractional IPv4 address).

Sorry for discussing irrelevant topics here but the main idea that came here took us to other topics.

Thanks,

Khaled

Kindest regards,

Olivier

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Nov 2018 13:32:33 -0500

Mr. Omar, layer 1 signaling is simply out of scope for the IETF.

On Mon, Nov 19, 2018 at 1:21 PM Khaled Omar <[email-masked]>
wrote:

> There are many issues here that needs some focusing then we can move to
> the main issue that has relevance to the WG charter, no.1 is the name of
> the new signal, we can't call it analogue just because it has different
> values, but we can call it digital because it encodes a digital stream into
> a new digital stream with limited values, no.2 the amount of information
> carried (I.e. what is the standard track that determines how many bits can
> be eencoded on every one output), no.3 compressing normal binary bits to
> compress 32 bits in 5 bits (so this will help in many things including
> compressing an IPv6 address to be 20 bits or increasing the IPv4 address
> space using fractional IPv4 address).
>
> *From:* Olivier MJ Crépin-Leblond <[email-masked]>
> *Sent:* Monday, November 19, 2018 2:02:52 PM
> *To:* Khaled Omar; [email-masked]; Simon Hobson
> *Subject:* [v6ops] IPmix version 01 modification.
>
>
>
> Look, electronically, what is 0 and what is 1, 0 is 0 voltage, and 1 is 5
> voltage, below 5 voltage is 0, 5 or over voltage is 1, so the values of
> voltages that can represent a 0 are listed on the file 0, 0.1, 0.2, etc and
> the values of voltages that can represent a 1 are 5, 5.1, 5.2, etc, so the
> 32 bits can be represented by 5 bits.
>
> Congratulations, you've just invented a digital to analogue converter. The
> problem is that these have been around for a long time. The other problem
> is that the type of encoding you're speaking about is similar to analogue
> TV signals like composite video etc. You immediately run into problems of
> phase, interference between the different signals as well as tolerance
> issues such as thermal and age tolerance - resistors and capacitors that
> change tolerance over time. That's without taking into account the
> Nyquist-Shannon sampling theorem and resulting Aliasing especially at
> higher frequencies.
>
> Olivier MJ Crépin-Leblond, PhDhttp://www.gih.com/ocl.html
>
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 19 Nov 2018 13:54:12 -0500

> Mr. Omar, layer 1 signaling is simply out of scope for the IETF.
Indeed. It is also (as stated by the chairs) out of scope for V6OPS (and
6MAN) -- the IEEE (https://www.ieee.org/) may be a place worth trying to
discuss this.
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: Khaled Omar <[email-masked]>
Date: Tue, 20 Nov 2018 19:30:19 +0000

Thanks, but I don't have experience with the ieee, I tried to contact them (Ethernet WG chair) to know how to use their website to submit a draft but I got no response till now.

First, I read about 10 pages to get information about how they work, but still unclear how the standardization process go there.

Khaled
________________________________
From: Warren Kumari <[email-masked]>
Sent: Monday, November 19, 2018 8:54:12 PM
To: Ted Lemon
Cc: Khaled Omar; Simon Hobson; IPv6 Operations
Subject: Re: [v6ops] IPmix version 01 modification.

On Mon, Nov 19, 2018 at 1:32 PM Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
Mr. Omar, layer 1 signaling is simply out of scope for the IETF.

Indeed. It is also (as stated by the chairs) out of scope for V6OPS (and 6MAN) -- the IEEE (https://www.ieee.org/) may be a place worth trying to discuss this.
W

On Mon, Nov 19, 2018 at 1:21 PM Khaled Omar <[email-masked]<mailto:[email-masked]>> wrote:
There are many issues here that needs some focusing then we can move to the main issue that has relevance to the WG charter, no.1 is the name of the new signal, we can't call it analogue just because it has different values, but we can call it digital because it encodes a digital stream into a new digital stream with limited values, no.2 the amount of information carried (I.e. what is the standard track that determines how many bits can be eencoded on every one output), no.3 compressing normal binary bits to compress 32 bits in 5 bits (so this will help in many things including compressing an IPv6 address to be 20 bits or increasing the IPv4 address space using fractional IPv4 address).

Thanks,

Khaled
________________________________
From: Olivier MJ Crépin-Leblond <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 19, 2018 2:02:52 PM
To: Khaled Omar; [email-masked]<mailto:[email-masked]>; Simon Hobson
Subject: [v6ops] IPmix version 01 modification.

Kindest regards,

Olivier

--
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: Khaled Omar <[email-masked]>
Date: Wed, 21 Nov 2018 19:43:14 +0000

I don’t see any e-mail ID representing a WG there, almost close to find a way to start a direct discussion and cannot find a single step-by-step guide, one more thing to mark, is there a page with all-in-one information to route for other pages other than what is mentioned in the recent website.

From: Warren Kumari [mailto:[email-masked]]
Sent: Monday, November 19, 2018 8:54 PM
To: Ted Lemon <[email-masked]>
Cc: Khaled Omar <[email-masked]>; Simon Hobson <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] IPmix version 01 modification.

Kindest regards,

Olivier

--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Nov 2018 14:46:34 -0500

You need to become a member, and generally your employer needs to become a
member as well.   Here's some introductory information:

https://standards.ieee.org/develop/index.html?utm_source=mm_link&utm_campaign=faw&utm_medium=std&utm_term=develop%20standards%2C%20find%20working%20group

On Wed, Nov 21, 2018 at 2:43 PM Khaled Omar <[email-masked]>
wrote:

> I don’t see any e-mail ID representing a WG there, almost close to find a
> way to start a direct discussion and cannot find a single step-by-step
> guide, one more thing to mark, is there a page with all-in-one information
> to route for other pages other than what is mentioned in the recent
> website.
>
>
>
> *From:* Warren Kumari [mailto:[email-masked]]
> *Sent:* Monday, November 19, 2018 8:54 PM
> *To:* Ted Lemon <[email-masked]>
> *Cc:* Khaled Omar <[email-masked]>; Simon Hobson <
> [email-masked]>; IPv6 Operations <[email-masked]>

---

From: Khaled Omar <[email-masked]>
Date: Wed, 21 Nov 2018 20:07:15 +0000

“and” or “or”?

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, November 21, 2018 9:47 PM
To: Khaled Omar <[email-masked]>
Cc: Warren Kumari <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] IPmix version 01 modification.

You need to become a member, and generally your employer needs to become a member as well.   Here's some introductory information:

On Wed, Nov 21, 2018 at 2:43 PM Khaled Omar <[email-masked]<mailto:[email-masked]>> wrote:
I don’t see any e-mail ID representing a WG there, almost close to find a way to start a direct discussion and cannot find a single step-by-step guide, one more thing to mark, is there a page with all-in-one information to route for other pages other than what is mentioned in the recent website.

From: Warren Kumari [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, November 19, 2018 8:54 PM
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Cc: Khaled Omar <[email-masked]<mailto:[email-masked]>>; Simon Hobson <[email-masked]<mailto:[email-masked]>>; IPv6 Operations <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] IPmix version 01 modification.

Kindest regards,

Olivier

--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Nov 2018 15:12:15 -0500

And.   I don't think individuals can participate in standards activity
there without a sponsor (I will admit that I'm not an expert, though).
 Remember, they are specifying how hardware works, and so it's important
that there be somebody making the hardware who can test the specification.

On Wed, Nov 21, 2018 at 3:07 PM Khaled Omar <[email-masked]>
wrote:

> “and” or “or”?
>
>
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Wednesday, November 21, 2018 9:47 PM
> *To:* Khaled Omar <[email-masked]>
> *Cc:* Warren Kumari <[email-masked]>; IPv6 Ops WG <[email-masked]>

---

From: Khaled Omar <[email-masked]>
Date: Wed, 21 Nov 2018 20:23:34 +0000

And … I understand, sounds like no chance, but giving up is not an option ☺

Sent: Wednesday, November 21, 2018 10:12 PM

And.   I don't think individuals can participate in standards activity there without a sponsor (I will admit that I'm not an expert, though).   Remember, they are specifying how hardware works, and so it's important that there be somebody making the hardware who can test the specification.

On Wed, Nov 21, 2018 at 3:07 PM Khaled Omar <[email-masked]<mailto:[email-masked]>> wrote:
“and” or “or”?

From: Ted Lemon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 21, 2018 9:47 PM
To: Khaled Omar <[email-masked]<mailto:[email-masked]>>
Cc: Warren Kumari <[email-masked]<mailto:[email-masked]>>; IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] IPmix version 01 modification.

Kindest regards,

Olivier

--

---

From: Paul Marks <[email-masked]>
Date: Wed, 21 Nov 2018 13:15:31 -0800

On Wed, Nov 21, 2018 at 12:24 PM Khaled Omar <[email-masked]>
wrote:

> And … I understand, sounds like no chance, but giving up is not an option
> J
>
>
You're likely to find that electrical engineers have already solved the
problem you're working on, decades ago.

For example:
- 100 Mbps Ethernet uses 2 voltage levels.
- 1 Gbps Ethernet uses 5 voltage levels (PAM-5 modulation).
- 2.5 / 5 / 10 Gbps Ethernet use 16 voltage levels (PAM-16 / 128-DSQ
modulation).

There are many more advanced coding techniques used by long-range copper,
optical, and wireless systems.

A protocol like IPv6 doesn't care how bits are transmitted through a
physical medium, as long as those bits can be reconstructed at the
receiving end.

---

From: Khaled Omar <[email-masked]>
Date: Wed, 21 Nov 2018 22:39:24 +0000

You're likely to find that electrical engineers have already solved the problem you're working on, decades ago.

For example:

Ø  - 2.5 / 5 / 10 Gbps Ethernet use 16 voltage levels (PAM-16 / 128-DSQ modulation).

First, the discussion was about compressing 32-bits into 5-bits that would help in compressing IPv6 address in L3 encapsulation, the solution was an encoder that works only with L1, and it is 32-bit to 5-bits which is something newer than your suggested encoders, the output is 5 bits represented in 100 different voltage values (still moree to do).

> A protocol like IPv6 doesn't care how bits are transmitted through a physical medium, as long as those bits can be reconstructed at the receiving end.

A good advantage, and the IPmix discussion should be around the clear details of v6-to-v4/v4-to-v6 as the I-D is describing with no confusion for the reader.

Kahled

From: Paul Marks [mailto:[email-masked]]
Sent: Wednesday, November 21, 2018 11:16 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

On Wed, Nov 21, 2018 at 12:24 PM Khaled Omar <[email-masked]<mailto:[email-masked]>> wrote:
And … I understand, sounds like no chance, but giving up is not an option ☺

You're likely to find that electrical engineers have already solved the problem you're working on, decades ago.

For example:
- 100 Mbps Ethernet uses 2 voltage levels.
- 1 Gbps Ethernet uses 5 voltage levels (PAM-5 modulation).
- 2.5 / 5 / 10 Gbps Ethernet use 16 voltage levels (PAM-16 / 128-DSQ modulation).

There are many more advanced coding techniques used by long-range copper, optical, and wireless systems.

A protocol like IPv6 doesn't care how bits are transmitted through a physical medium, as long as those bits can be reconstructed at the receiving end.

---

From: Paul Marks <[email-masked]>
Date: Wed, 21 Nov 2018 15:54:57 -0800

On Wed, Nov 21, 2018 at 2:39 PM Khaled Omar <[email-masked]>
wrote:

> First, the discussion was about compressing 32-bits into 5-bits that would
> help in compressing IPv6 address in L3 encapsulation, the solution was an
> encoder that works only with L1, and it is 32-bit to 5-bits which is
> something newer than your suggested encoders, the output is 5 bits
> represented in 100 different voltage values (still moree to do).
>
>
>

Okay, here's another example: 256-QAM (commonly used with cable modems) can
represent 8 bits per symbol:
- An IPv4 address needs 4 symbols
- An IPv6 address needs 16 symbols

But this example doesn't help, because QAM symbols are *not bits*; see
below.

> A good advantage, and the IPmix discussion should be around the clear
> details of v6-to-v4/v4-to-v6 as the I-D is describing with no confusion for
> the reader.
>

Even if you could represent an entire IPv6 address using a single voltage
(out of 340 undecillion possible voltages), you would be no closer to
implementing an IPv4-to-IPv6 transition mechanism, because IP addresses are
not made of voltages.  They are made of bits, and the number of bits is
fixed by their definition.

A bit is a mathematical idea; it can only have two states: 0 or 1.

Fitting more than two states into a bit (or more than 32 states into 5
bits, etc.) is logically impossible, like a 5-sided triangle or a chess
board with 49 squares.  You could make a 5-sided figure, but it wouldn't be
a triangle, and you could make a 49-square game board, but it wouldn't be a
chess board.

Likewise, you could compress an IPv6 address into 32 (or 20, or 5) *things*,
but those *things* would not be bits, and the result would not be an IPv4
address.

In mathematics, some problems are truly unsolvable.  When you encounter
such a problem, the correct solution is to give up and do something else.

---

From: Khaled Omar <[email-masked]>
Date: Thu, 22 Nov 2018 10:39:08 +0000

> In mathematics, some problems are truly unsolvable. When you encounter such a problem, the correct solution is to give up and do something else.

And... is it real to find unsolvable problem!
________________________________
From: Paul Marks <[email-masked]>
Sent: Thursday, November 22, 2018 1:54:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

On Wed, Nov 21, 2018 at 2:39 PM Khaled Omar <[email-masked]<mailto:[email-masked]>> wrote:
You're likely to find that electrical engineers have already solved the problem you're working on, decades ago.

For example:

Okay, here's another example: 256-QAM (commonly used with cable modems) can represent 8 bits per symbol:
- An IPv4 address needs 4 symbols
- An IPv6 address needs 16 symbols

But this example doesn't help, because QAM symbols are not bits; see below.

Even if you could represent an entire IPv6 address using a single voltage (out of 340 undecillion possible voltages), you would be no closer to implementing an IPv4-to-IPv6 transition mechanism, because IP addresses are not made of voltages.  They are made of bits, and the number of bits is fixed by their definition.

Fitting more than two states into a bit (or more than 32 states into 5 bits, etc.) is logically impossible, like a 5-sided triangle or a chess board with 49 squares.  You could make a 5-sided figure, but it wouldn't be a triangle, and you could make a 49-square game board, but it wouldn't be a chess board.

Likewise, you could compress an IPv6 address into 32 (or 20, or 5) things, but those things would not be bits, and the result would not be an IPv4 address.

In mathematics, some problems are truly unsolvable.  When you encounter such a problem, the correct solution is to give up and do something else.

---

From: Khaled Omar <[email-masked]>
Date: Fri, 23 Nov 2018 15:50:31 +0000

> Fitting more than two states into a bit (or more than 32 states into 5 bits, etc.) is logically impossible, like a 5-sided triangle or a chess board with 49 squares. You could make a 5-sided figure…

You can make a new figure from triangles and call it a pyramid, it still consists of triangles, same as representing a 1 with multiple values, these values can be voltages, etc.

The idea is if you can add something new, then add it, of course it will not be totally new thing but it will consists of other known things, this is called development, why there is a fear of adding something new, if you discovered something that will add a value, mark it and do it, it is your right.

For example:

---

From: Gert Doering <[email-masked]>
Date: Fri, 23 Nov 2018 16:52:35 +0100

Hi,

> The idea is if you can add something new, then add it, of course it will not be totally new thing but it will consists of other known things, this is called development, why there is a fear of addi…

The IETF is a very strong believer in "running code".

Please provide code that shows that your ideas are feasible.

Gert Doering
        -- NetMaster

---

From: Khaled Omar <[email-masked]>
Date: Fri, 23 Nov 2018 15:56:06 +0000

Out of my hands.
________________________________
From: Gert Doering <[email-masked]>
Sent: Friday, November 23, 2018 5:52:35 PM
To: Khaled Omar
Cc: Paul Marks; [email-masked]
Subject: Re: [v6ops] IPmix version 01 modification.

Hi,

Gert Doering
        -- NetMaster