Hi,

> An "update" that is more complex than an "upgrade" to IPv6. It requires 
> changes to routers to handle the packets, it requires changes to hosts to 
> handle the packets, it requires changes to routing etc etc etc.

Updating --> does not depends on clients (can we try to decrease the changes?).
Upgrading --> depends on clients (will we keep waiting them until the end of 
days!).

P.S. clients have the right not to upgrade, there are no benefits, it is not 
their problem that people who designed IPv4 didn't make the address large 
enough to cover the huge expansion, so they shouldn't solve a problem that is 
not their own, this is how they think.

Khaled

-----Original Message-----
From: Sander Steffann [mailto:[email protected]] 
Sent: Wednesday, November 14, 2018 2:23 PM
To: Khaled Omar <[email protected]>
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [v6ops] IPmix I-D version 01.

Hi,

> Let's take it step by step, first I'm not asking the IETF to publish the 
> document as an RFC as version 01, there are more to add.
> 
>> This is simply wrong: "IPv4 only" and "IPv6 only" hosts would not be able to 
>> speak IPmix by definition of "only". This is a fundamental contradiction in 
>> your proposal. 
> 
> "Only" means the assigned IP address for the host is either IPv4 only or IPv6 
> only.

"Only" doesn't just refer to the addresses, it refers to the entire protocol 
stack.

>> If an IPv4 host would be upgraded with IPmix, there is no reason to not let 
>> it upgrade to IPv6 and be it a dual stack host. Problem solved.
> 
> IPmix is not an address as IPv6 to be assigned, the host will not be upgraded 
> but it will be updated.

An "update" that is more complex than an "upgrade" to IPv6. It requires changes 
to routers to handle the packets, it requires changes to hosts to handle the 
packets, it requires changes to routing etc etc etc.

This draft doesn't help in any way, and therefore should be dropped.

Cheers,
Sander

PS: you have tried this before, and since you don't seem to get the message let 
me be blunt: this whole idea is BS, you don't seem to have a clue about 
protocol design, implementation, interactions and deployment, so please 
withdraw this and stop wasting our time.

PPS: sorry to the rest of the list for the bluntness

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to