Re: [sig-policy] The Choice: IPv4 Exhaustion or Transition to IPv6
The document is not perfect, I know, but I think it is useful for
non-technical managers that know almost nothing about address distribution,
PDP, etc. and mainly the IPv4 exhaustion problem.
See also below, in-line.
Regards,
Jordi
> De: Tim Jones <tim at iseek dot com dot au>
> Responder a: <tim at iseek dot com dot au>
> Fecha: Thu, 28 Jun 2007 10:57:27 +1000
> Para: "'jordi.palet at consulintel dot es'" <jordi.palet at consulintel dot es>,
> "sig-policy at lists dot apnic dot net" <sig-policy at lists dot apnic dot net>
> Conversación: [sig-policy] The Choice: IPv4 Exhaustion or Transition to IPv6
> Asunto: RE: [sig-policy] The Choice: IPv4 Exhaustion or Transition to IPv6
>
> Hi Jordi,
>
> You make some statements in your document that I think need some
> substantiation.
>
> I know there are a lot of people on this list who despise NAT, but you say:
>
> "peer-to-peer applications are very expensive and complex to develop when even
> a single NAT is present".
>
> And then later in the document you say that peer-to-peer software development
> will be 80% cheaper when NAT is removed.
This is something that has been said even by people like Skype. I don't want
to enter into a debate about that. You may want to say I've exaggerated, but
others may disagree with you :-)
>
> Given the widespread deployment of free file sharing software that only
> requires a simple port forward to work, I really think that you need to
> provide some supporting evidence.
>
> Then later again (page 10) you say that upgrading ISP and Enterprise networks
> and re-training staff is only a minimal cost. Amongst other similar
> statements, you mention (paraphrasing for berevity):
>
> "Given that the cost of upgrading to IPv6 is so insignificant...there are
> clear advantages to saving on the cost of supporting NAT connected customers"
>
> If I am not mistaken, you seem to be trying to insinuate that supporting NAT
> customers is more expensive than upgrading an ISP network to IPv6?
Big operators have stated in meetings like NANOG about the cost of
supporting users that call because NAT. This cost has been evaluated by them
and I think it is bigger than the cost of supporting issues with IPv6.
So even if I was not trying to say what you're reading, in the long term, we
may say yes, it may be possible, but it depends a lot of how big is the
network, how many users, what applications, etc. Definitively not valid as a
generic statement.
>
> Your arguments seem a tad simplistic to be honest. Yes IOS, JunOS etc etc
> support, and have for some time IPv6, but there is a myriad of other devices,
> software and staff (especially software and staff) that exist in an
> ISP/Enterprise environment where it is not just a case of loading the latest
> vendor image, plug it into an IPv6 carrier and it'll work.
I the document I'm never stating a full blown native IPv6 support, I'm
assuming dual-stack support in hosts, and using transition mechanisms.
>
> In any medium organization or larger there are going to be hundreds of
> scripts, config files, billing/accounting/provisioning/metering systems,
> firewall rules etc. etc. that need to be checked and updated (think Y2K) to
> ensure that they are IPv6 ready.
Not overnight. Remember, what I'm saying is "be ready, plan ahead, don't
close your eyes to IPv6", make it at your own pace to reduce the cost.
>
> I wish it was as simple as you seem to suggest, and that in an IPv6 Utopia the
> streets would be paved with gold.
>
> Unfortunately I don't think it will be simple, and I don't think the benefits
> will be anything more than additional address space.
And last, but not least, my document is not trying to sell IPv6. Is trying
to explain what is the IPv4 exhaustion and what are the mitigations, in the
short term, and the long-term, and it seems to me that IPv6 is what we have
for the long-term, we like it or not, even if it is not so easy I say, is
what we have.
>
> Cheers,
> Tim.
>
>
>> -----Original Message-----
>> From: sig-policy-bounces at lists dot apnic dot net [mailto:sig-policy-
>> bounces at lists dot apnic dot net] On Behalf Of JORDI PALET MARTINEZ
>> Sent: Thursday, 28 June 2007 5:04 AM
>> To: sig-policy at lists dot apnic dot net
>> Subject: [sig-policy] The Choice: IPv4 Exhaustion or Transition to IPv6
>>
>> Hi all,
>>
>> I've published a document trying to analyze the IPv4 exhaustion problem
>> and
>> what is ahead of us, considering among others, changes in policies.
>>
>> http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004
>>
>> I guess this could be useful in order to understand possible implications
>> of
>> modifying existing policies, or setting up new ones, or even just to
>> create
>> some debate about those changes.
>>
>> The document was completed last April, but didn't had the time to tidy up
>> until a few days ago.
>>
>> Regards,
>> Jordi
>>
>>
>>
>>
>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Bye 6Bone. Hi, IPv6 !
>> http://www.ipv6day.org
>>
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>>
>>
>>
>> * sig-policy: APNIC SIG on resource management policy
>> *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.