I disagree. I don't object to having a solution that also helps IPv4,
but I do not think it is as important as getting something that works
for IPv6.
We can keep the IPv4 net working for quite a while. Particularly if we
can provide some reason for folks to believe that v6 will matter. If
there is some actual benefit to the users (like better multi-homing)
from IPv6, then not only will folks move towards it, but folks will
believe that it is likely to matter, which reinforces the effect. This
in turn should help keep the pressure on v4 within the manageable range.
Note that trying to do this without solving the architectural probloems
will merely result in v6 continuing to be ignored. Or worse, v6
becoming an even worse case of the problems we have with v4.
Joel
Scott Brim wrote:
On 6/6/08 12:45 PM, Tony Li allegedly wrote:
Our recommended solution should be applicable to IPv6. It may also
apply to
IPv4, but at the very least must provide a path forward for IPv6.
I think applicability to IPv4 is equally important. First, it will be
years before there are more IPv6 packets than IPv4 packets -- longer
than the time frame in which we must get our new technology deployed --
and efficient control of IPv4 forwarding is important. Second, the
granularity of IPv4 allocations is very probably going to go up
dramatically in these final days, and that "state*rate" load will not go
away for a long time. We will have to carry it in routing until
(unless) we deal with multihoming, hijacking, etc. for IPv4.
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
