In my opinion, I don't see a problem with this thread. I believe it is useful to see how v6 is being deployed or reasons why it is not being deployed.
So, as long as it remains civil and doesn't degrade into a re-hash of past arguments, I don't see a problem with it continuing.
Regards, Brian
Bound, Jim wrote:
Question to Chairs:
This appears to be a marketing discussion for IPv6 deployment? I personally think it is useful. But do the chairs want this thread to continue. Reason, if it is to continue then additional input to response below would be actual deployment in process that is not waiting on the multihome solution specifically Military and Telco operations in the market and then there is the Moonv6 US Network Pilot in process where 25 vendors are testing products as I type this email. www.moonv6.com
Should this thread continue with the support of the Chairs. My vote is yes but then it will add a thread that increases mail that does not work on our engineering problems at hand? But if you say it should stop I am fine with that too. Just trying to understand what mail flow you want to support here and for us to be "consistent" with that rule for the WG.
Thanks /jim
-----Original Message-----
From: Mans Nilsson [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 11:33 AM
To: Mark Smith
Cc: [EMAIL PROTECTED]
Subject: Re: Will IPv4 be formally deprecated when IPv6 is good enough ?
Subject: Will IPv4 be formally deprecated when IPv6 is good enough ? Date: Tue, Oct 14, 2003 at 11:43:36PM +0930 Quoting Mark Smith ([EMAIL PROTECTED]):
That brings to my mind two questions
a) Is IPv4 going to be formally deprecated when IPv6 is
good enough?
If so, are the related IPv4 NAT RFCs also going to be deprecated at that time ?
Do not think so. Maybe it is my limited mind, but I find it hard not to keep v4 on some boxes.
b) Is IPv6 good enough yet ?
I think so. There are valid concerns on two things; multihoming and address allocation procedures. There seems to be strong forces among the researchers and vendors advocting that we halt and wait for the Grail of multihoming while we at the same time work very hard in preventing people from getting allocations, to preserve address space and keep the routing table size down.
I think the address allocation problem is based on v4 habits. v6 is abundant. We need it to be available. Nothing will happen until people can get real allocations with relative ease, not so easy that nuisance allocations will occur, but almost. Give every AS number holder a /32 or something, and watch deployment speed up.
With multihoming, strongly related to above, I suggest people cease waiting for the Grail and instead adopt the v4 model, aided by the limited growth we'd see if people did not have to patch their nets together using disjunct prefixes. I believe routing table growth would be much slower, and there are suggestions I find supportive of this in some analyses of routing table characteristics, for example in > <http://www.caida.org/outreach/papers/2002/EGR/>> :
"Small ASes (those who originate only a few prefixes into
the global routing system) do not contribute more than their
fair share of either route entries or churn to the global
routing system."
Thus, if most ASen were able to contain all their hosts within one single /32 per AS, we would see limited routing table growth for some years, during which there would be time to develop more sophisticated routing paradigms, if operational experience dictated such a need was indeed present.
The key words here are "operational experience". We need to get people start using v6 for everyday things.
-- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
This TOPS OFF my partygoing experience! Someone I DON'T LIKE is talking to me about a HEART-WARMING European film ...
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
