Subject: Re: [Int-area] Fw: Continuing IPv10 I-D discussion.

From: Khaled Omar <[email-masked]>
Date: Sat, 1 Apr 2017 11:10:22 +0000

Joel,

The idea is to let devices handling the IPv10 packet to understand what is the IP address stored within the IPv10 packet whether it is an IPv4 or an IPv6 address, the field size is fixed (128-bit) so in case of an IPv4 address, the 1st 96-bits should be 0s, once a device finds out these 0s in the 1st 96-bits, and a binary stream in the 2nd 32-bits, it must understand that this address is an IPv4 address, it is that easy.

-----Original Message-----
From: joel jaeggli [mailto:[email-masked]] 
Sent: Saturday, April 1, 2017 7:11 AM
To: Khaled Omar; Tom Herbert
Cc: [email-masked]
Subject: Re: [Int-area] Fw: Continuing IPv10 I-D discussion.

On 3/31/17 09:24, Khaled Omar wrote:
>> "all OSs will be updated to support IPv10 which is an easy task"...
>>> What makes you think it is ever an easy task to get all OSes to 
>>> uniformly support anything? Please provide an implementation so we 
>>> can evaluate the prospects.
> 
> For the 2nd time:
> 
> "I shouldn't list all devices that need to support IPv10, simply, 
> anything will process a L3 packet, should understand that the IPv10 
> packet can contain a mixture of IPv4 and IPv6 addresses."

Assuming for the sake of argument that I am designing a forwarding asic.
When I pass over the ethertype code in the frame, I decide what forwarding lookup path I am going to exercise the ipv4 or ipv6 one. If i choose door number 1 the ipv4 path  due to 0x0800  and destination mac being me the byte offset for the source is 12 and the destination is 4 bytes later at byte offset 16. if these fields are of variable length then a 16 byte source address overflows the fixed offset  where the destination  is supposed and the destination address is lost to me because it's where optional fields might otherwise be.

If I choose the v6 path due to 0x86DD then I find the source address address at byte 8 and the destination beginning at byte 24 there, there are of course several ways to represent a an ipv4 mapped address within ipv6, none of them are of any use to an native ipv4 speaker.

The fields in the packet header are not self-described (they could be, packet header could be json for example  but in the interest of performance they were / are not), therefore  in the interestes of clarity a new ethertype for ipv10 with either a fixed size source and destination address size  or a whay of specifying the offset, and a bit or multiple bit field for the AF of both the source and destination would greatly facilitate the design of a parser that would be able to handle the selection of AF for lookup. at the point you've go an entirely new header which is not compatible with either V4 or V6 parsers. in practical terms that means the useful deployment of a v10 compatible parser at internet scale is approximately as hard as deploying the the v6 compatible parser would be if we started now instead of in 1995 when the internet was much smaller.

joel

> 
> -----Original Message----- From: Tom Herbert 
> [mailto:[email-masked]] Sent: Friday, March 31, 2017 4:19 PM To:
> Khaled Omar Cc: Bless, Roland (TM); [email-masked] Subject: Re:
> [Int-area] Fw: Continuing IPv10 I-D discussion.
> 
> On Fri, Mar 31, 2017 at 5:13 AM, Khaled Omar 
> <[email-masked]> wrote:
>>> As has been stated again and again. Your proposal would have been 
>>> interesting if it was presented in 1995, or perhaps even in 2000.
>> 
>> FYI, IPv10 will allow IPv4 to communicate to IPv6 and vice versa, how 
>> can it be interesting if it was presented before IPv6 was even 
>> developed !
>> 
>>> Most likely, even if Microsoft could be convinced that IPv10 is 
>>> something they need to support, this would only happen in Windows 
>>> 10. Then we have the rest of the ecosystem with access routers, load 
>>> balancers, SAVI-functionality for BCP38 compliance in access 
>>> devices, core routers etc.
>> 
>> Please, let's not be against ourselves, all OSs will be updated to 
>> support IPv10 which is an easy task, OSs will not require support for 
>> a new IP version like IPv6, they will just be enabled to support the 
>> encapsulation of both version on the same L3 packet header.
> 
> "all OSs will be updated to support IPv10 which is an easy task"... 
> What makes you think it is ever an easy task to get all OSes to 
> uniformly support anything? Please provide an implementation so we can 
> evaluate the prospects.
> 
> Tom
> 
>> 
>> Also, networking devices will be upgraded to understand the new
>> IPv10 packet, I said earlier I don't mind If the process will take 
>> some time but we should eventually reach consensus, I shouldn't list 
>> all devices that need to support IPv10, simply, anything will process 
>> a L3 packet, should understand that the IPv10 packet can contain a 
>> mixture of IPv4 and IPv6 addresses.
>> 
>> 
>> -----Original Message----- From: Int-area 
>> [mailto:[email-masked]] On Behalf Of Bless, Roland (TM)
>> Sent: Friday, March 31, 2017 9:51 AM To: Mikael Abrahamsson Cc:
>> int-area Subject: Re: [Int-area] Fw: Continuing IPv10 I-D discussion.
>> 
>> Hi Mikael,
>> 
>> thanks for clarifying again, everything +1!
>> 
>> Regards, Roland
>> 
>> Am 31.03.2017 um 08:17 schrieb Mikael Abrahamsson:
>>> On Thu, 30 Mar 2017, Khaled Omar wrote:
>>> 
>>>> You can read the IPv10 I-D again and all your concerns will be  
>>>> obvious, I don't mind if you have already a series of new questions 
>>>> that will add a new value to the discussion but the time to deploy 
>>>> IPv10 is an important factor.
>>>> 
>>>> We need consensus after understanding how IPv10 works and how it 
>>>> will be deployed.
>>> 
>>> As has been stated again and again. Your proposal would have been  
>>> interesting if it was presented in 1995, or perhaps even in 2000.
>>> 
>>> Let me give you an IPv6 deployment timeline:
>>> 
>>> Standards were worked out in the mid 90-ties, afterwards operating 
>>> system vendors started working on it and "real" support started 
>>> cropping up in the early to mid 2000:nds, with a large milestone 
>>> being Windows Vista in 2006, where as far as I know this was the 
>>> first widely used consumer operating system to implement this. It 
>>> then took until Windows 7 timeframe around
>>> 2010 before people started moving off of Windows XP in ernest, and 
>>> we're still seeing Windows XP in non-trivial numbers. So now in 2017 
>>> we're seeing most operating systems have comprehensive (albeit 
>>> perhaps not as well-tested as we would like) support for  IPv6, 
>>> where the application ecosystem still has a way to go.
>>> We're still working on better APIs to handle the dual-stackedness 
>>> problem.
>>> 
>>> Most likely, even if Microsoft could be convinced that IPv10 is 
>>> something they need to support, this would only happen in Windows 
>>> 10. Then we have the rest of the ecosystem with access routers, load 
>>> balancers, SAVI-functionality for BCP38 compliance in access 
>>> devices, core routers etc. Most of these will require a hardware 
>>> fork-lift in order to support your proposal, because they do not 
>>> forward packets in a CPU, they forward it in purpose-designed 
>>> hardware that is a lot less flexible in what they can do.
>>> 
>>> So even if we all united now (which won't happen) around your
>>> IPv10 proposal, it would take 5-10 years before the first devices 
>>> out on the market had support for it. Probably 5-10 years after that 
>>> before support is widely available.
>>> 
>>> IPv10 would delay and confuse deployment of something that is not 
>>> IPv4. While IPv6 is not perfect, there are now hundreds of millions 
>>> of devices on the Internet with IPv6 access. It's proven to work, 
>>> it's not perfect, but we have a decently good idea what to do to 
>>> make it better.
>>> 
>>> IPv10 is only injecting FUD into where we need to go debate, which 
>>> is IPv6 deployment for all.
>>> 
>>> Please stop.
>> 
>> _______________________________________________ Int-area mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/int-area
>> 
>> _______________________________________________ Int-area mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/int-area
> _______________________________________________ Int-area mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Khaled Omar <[email-masked]>
Date: Sat, 1 Apr 2017 11:12:48 +0000

> If I choose the v6 path due to 0x86DD then I find the source address address at byte 8 and the destination beginning at byte 24 there, there are of course several ways to represent a an ipv4 mapped…

That's why all Internet hosts must be IPv10 hosts.

-----Original Message-----
From: joel jaeggli [mailto:[email-masked]] 
Sent: Saturday, April 1, 2017 7:11 AM
To: Khaled Omar; Tom Herbert
Cc: [email-masked]
Subject: Re: [Int-area] Fw: Continuing IPv10 I-D discussion.

joel

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 1 Apr 2017 13:21:54 -0500

> That's why all Internet hosts must be IPv10 hosts.

If all hosts can be made IPv10, they can all be made IPv6. Thereby reducing this to a previously solved problem.

... or should I have looked more closely at the posting date?

Stewart

---

From: Khaled Omar <[email-masked]>
Date: Sat, 1 Apr 2017 18:45:33 +0000

Steqart,

IPv10 is a software update modification (by technology companies), IPv6 migration process requires planning, implementation, configuration, support, etc (by enterprise customers and ISPs), very big difference.

-------- Original Message --------
Subject: Re: [Int-area] Fw: Continuing IPv10 I-D discussion.
From: Stewart Bryant
To: Khaled Omar
CC: joel jaeggli ,[email-masked]

Stewart