Victor Kuarsingh wrote:
However, 224/4 (or most of it) and 240/4 (except for 255.255.255.255)
should be released for unicast uses to reduce market price on
IPv4 addresses.
I have not objection to this. But anything that requires replacement of
equipment only will have longer term benefit. (Built it, Ship it, Stock
it, Sell it, put it in....).
Remember that the current IPv6 is not operational, because of
implosions of ICMPv6 packet too big generated against multicast
packets, which means it takes time to fix ICMPv6 operational
before "Built it, Ship it, Stock it, Sell it, put it in...."
I would also hope that when we have an
opportunity to change out a box, it's with a IPv6 capable one (although it
does not help that many boxes on the retail shelf are still IPv4-only -
where we are).
Thus, it is easier to expand IPv4 address space using port
numbers as specified in RFC3102:
RSIP is intended as a alternative to NAT in which the end-
to-end integrity of packets is maintained.
or something like that, which is recently called port restricted
IP.
I wish to spend most of our time on IPv6 deployment (and only do what is
necessary for IPv4 to keep the lights on). Activity working on getting
equipment to utilize 240/4 seems like a lot of effort.
The problem is that IPv6 is broken, which means its
deployment is meaningless until it is fixed.
The multicast PMTUD example above is just an example and
there are other problems in IPv6 specification.
but I am not sure if the IETF is the right place to attempt and
control market forces and the IPv4 Futures Market.
Instead, from my experience to fix the so obvious multicast
PMTUD problem within IETF, I'm sure IETF is not the right
place to attempt to fix IPv6, which means IPv6 is hopeless.
Masataka Ohta
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf