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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf