Tom,
Looks like that you read old version of the draft, the latest version is version 12.
Best regards,
Khaled Omar
From: Tom Beecher <beecher@xxxxxxxxxx>
Sent: Monday, October 10, 2022 4:32 PM
To: Khaled Omar <eng.khaled.omar@xxxxxxxxxxx>
Cc: ietf@xxxxxxxx
Subject: Re: IPv6 adoption - IPv10 is the future.
I’ve never seen an IPv6 address that start like that 0:0:0:6018:9560:2F74:1107:2008, where from this 128-bits you can extract the MAC address 60-18-95-60-2F-74 and the IPv4 address 110.7.20.8, can you refer to an RFC that uses the first
48-bits of an IPv6 address as 0’s?
RFC4291: IP Version 6 Addressing Architecture
- 2.5.2 : The Unspecified Address ( All 0s)
- 2.5.3 : The Loopback Address ( ::/1)
- 2.5.4 : Global Unicast Address ( There is no prohibition against the global routing prefix or subnet ID , combined, not being 48 or more bits of 0s. )
- 2.5.5.1 : IPv4-Compatible IPv6 Address ( First 80 bits, 0's. )
- 2.5.5.2 : IPv4-Mapped IPv6 Address ( First 80 bits, 0's. )
I’ll give you an example of the VPN (RFC 2764) and VxLAN (RFC 7348), both encapsulates the original IP header and frame respectively in a new header and the routers and switches can understand the new header and process it, where is the
problem with the new proposed IP header?
You said the magic words yourself : "new header" . The new header is a standard v4 or v6 IP header. Any inner IP headers don't 'matter'. This is a standard encapsulation / tunneling concept.
Hi Tom,
It is good that you don’t listen to others and make your own comments as you did now, it is really appreciated.
>> Any statements that a new IP version could possibly be deployed 'in a short time' flies in the face of reality.
Can you tell me this update will depend on whom to be deployed?
>> You propose to encode the first 48 bits of an IPv4 address as 0's as a signal to a router that the field contains a V4 address. A router cannot do that, because multiple IPv6
addresses with specific functions already exist that start with more than 48 0's.
I’ve never seen an IPv6 address that start like that 0:0:0:6018:9560:2F74:1107:2008, where from this 128-bits you can extract the MAC address 60-18-95-60-2F-74 and the IPv4 address
110.7.20.8, can you refer to an RFC that uses the first 48-bits of an IPv6 address as 0’s?
>> Also ,you propose encoding MAC addresses in this header. Why?
To know the identity of the sending host.
>> Your proposed new IP header is not really defined. If you look at RFC 791 for IPv4 and RFC8200 for IPv6, you will see that all information in the header is specified down to
the bit position. Any new IP header would need the same level of detail.
>> Your proposed ordering of SRC/DST IP to be v4/v6 OR v6/v4 would create absolute nightmares for chip and software design. For the existing IP headers, the source and dest addresses
are in fixed order and bit positions. Your proposal would require an additional parse step or the source or dest to decide if it contained a v4 or v6 address before being able to do anything else. This would create massive overhead for no benefit over existing
mechanisms.
I’ll give you an example of the VPN (RFC 2764) and VxLAN (RFC 7348), both encapsulates the original IP header and frame respectively in a new header and the routers and switches
can understand the new header and process it, where is the problem with the new proposed IP header?
Best regards,
Khaled Omar
Khaled-
Although I have been told it has been done before, I will endeavor to call out some very specific technical reasons why your idea isn't likely to garner much interest.
1. You propose IPv10 as a new IP header. Section 2, point 4 :
>- The new IPv10 header contains a source and destination IP addresses
from two different versions.
In Section 5, point 5, you then state :
> 5) IPv10 support on "all" Internet connected hosts can be deployed
in a very short time by technology companies developing OSs
(for hosts and networking devices, and there will be no
dependence on enterprise users and it is just a software
development process in the NIC cards of all hosts to allow
encapsulating both IPv4 and IPv6 in the same IP packet header.
This is a massively incorrect assumption. IPv6 was first officially standardized more than 25 years ago, and network equipment and software are regularly released in the present without complete support for it. Any statements that a new IP version could possibly
be deployed 'in a short time' flies in the face of reality.
2. You propose to encode the first 48 bits of an IPv4 address as 0's as a signal to a router that the field contains a V4 address. A router cannot do that, because multiple IPv6 addresses with specific functions already exist that start with more than 48 0's.
Also ,you propose encoding MAC addresses in this header. Why?
3. Your proposed new IP header is not really defined. If you look at RFC 791 for IPv4 and RFC8200 for IPv6, you will see that all information in the header is specified down to the bit position. Any new IP header would need the same level of detail.
4. Your proposed ordering of SRC/DST IP to be v4/v6 OR v6/v4 would create absolute nightmares for chip and software design. For the existing IP headers, the source and dest addresses are in fixed order and bit positions. Your proposal would require an additional
parse step or the source or dest to decide if it contained a v4 or v6 address before being able to do anything else. This would create massive overhead for no benefit over existing mechanisms.
I cannot imagine how such people are working at the IETF, what is this level of hatred!!!!
If you don’t support IPv10 then say your opinion respectfully or keep silence.
Who is this person, someone tells me please, because he acts as the founder of the IETF or as a rude chair :D
Khaled Omar
As IAB Reviewer I will not repeat my self many times. No need to IPv10.
Close this thread immediately and Go far please from IETF.
You do somethings imaginable we are not here to copy each other and bring oldies or googles in flavor of Internet communities.
Please Go away, Please Go away, Please Go away and work on your IPv10.
I agree with you, but IMHO IPv10 I-D didn't get full chance to be presented here at the IETF, the issue is that a lot really think it is the best recent solution and others don't think
so, and I bet on this draft.
Also, the recent situation is critical IMHO because of the depletion of IPv4 and no full migration to IPv6 occurred till now even after this looong time.
Best regards,
Khaled Omar
-----Original Message-----
From: Hannes Tschofenig <Hannes.Tschofenig@xxxxxxx>
Sent: Friday, October 7, 2022 1:57 PM
To: Toerless Eckert <tte@xxxxxxxxx>; Khaled Omar <eng.khaled.omar@xxxxxxxxxxx>
Cc: ietf@xxxxxxxx
Subject: RE: IPv6 adoption - IPv10 is the future.
The situation appears to be pretty simple to me.
Let's level up a bit: When new work is proposed in the IETF, sometimes there is excitement about it and others want to work on it (review, contribute, implement and even deploy). But there are, of course, also cases where ideas are not considered worthwhile
to pursue. That happens for a number of reasons.
So, there is nothing unusual happening here. Some ideas fly - others crash.
Ciao
Hannes
-----Original Message-----
From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Toerless Eckert
Sent: Tuesday, October 4, 2022 1:39 AM
To: Khaled Omar <eng.khaled.omar@xxxxxxxxxxx>
Cc: ietf@xxxxxxxx
Subject: Re: IPv6 adoption - IPv10 is the future.
Khaled,
I have never seen over the years, how draft-omar-ipv10 would have seriously added text that reflects and discusses the feedback it did receive over the years.
That would have made it become a much more useful document, even if just to show that maybe the solution proposed does not offer sufficient additional value.
There are at least 24+ transition solutions between IPv4 and IPv6 (https://en.wikipedia.org/wiki/IPv6_transition_mechanism),
each of which targeted for one or more deployment cases where IPv6 needed to be added with the least amount of work/cost/effort and still allow to connect to IPv4. Any new proposal like yours that is primarily attempting to accelerate the adoption of IPv6 would
have to present exact, practical deployment examples with topology and explanation which pieces shouldn't be updated to reduce cost, and explain how its approach results in less upgrade work compared to any of those exiting mechanisms. That is almost impossible
IMHO given how many solutions there are.
There is of course also the much more fundamental issue of there not being enough added value in IPv6 over IPv4 except for address exhaustion. Yes, we have done a long list of smaller enhancements, and to engineers it is quite frustrating to be told "the old
is good enough, thank you very much", but to me this is just the motivation to reach further with network layer enhancements than what your IPv10 is proposing - to make it worth the while for more deployments. For example, several more recent proposals in
the IETF are loooking into variable length addresses as a tool to achieve a lot more flexibility for future network services, so i think it would be a big waste to stick fixated to only existing IPv4/IPv6 addresses. Those two type of addresses should just
be the most important aspects of backward compatibility for any next-generation network layer work - to avoid the forklift upgrade issue we created with IPv6 and/or those 24 transition solutions we then had to introduce to overcome the forklift.
Last but not least: None of network layer innovation problems are going to be solved IMHO as long as we do not better understand how we foremost need the ability of actual parties interested in innovation to have the ability to get it deployed. Today, this
limits all novel network layer innovation to overlay models in DCs at the edge of domains in VM/software. If we want to get into the underlying networks, we need that underlying network hardware to become as easily programmable by third parties as VMs in DCs
are. Alas, the IRTF/COIN has not shown any interest to discuss that topic, even though to me that is the most core "compute in the network" i can think of. And it would be the logical next step beyond the current "configured slices"
(programmable slices).
Aka: Think beyond IPv6+4 ;-)
Cheers
Toerless
On Tue, Sep 20, 2022 at 05:13:29PM +0000, Khaled Omar wrote:
Hi IETFers,
I still see no progress happens in the IPv6 deployment all over the world and 5 years ago when we started to do analysis we found out now that the migration process going so slow and now the percentage according to google hits 40% which gives an alarm of the
internet division due to finding blocks of IPv6 only hosts and IPv4 only hosts in the internet.
[cid:image003.png@01D8CD25.0F2F45F0]
I don't know why till now the IETF didn't take the IPv10 draft seriously into consideration as it would be applied since it was developed and it wouldn't take so much time to be deployed in the internet.
I still see no better solution, not because I'm the IPv10 I-D author, but because I keep watching what's going on on the internet and I see the red flag case will be raised soon due to the incompatibility between IPv4 and IPv6.
I hope I get positive replies because of course I'm not aware with everything happening at the IETF.
Have a good day everyone.
Best regards,
Khaled Omar
Senior Service Delivery Engineer
DELL Technologies, Egypt
--
---
tte@xxxxxxxxx
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
|
