Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] Do we push for more V4 or advocate dual stack ??

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Fri Aug 31 06:06:58 UTC 2007


Hi David,

See below, in-line.

Regards,
Jordi




> De: David Conrad <drc at virtualized.org>
> Responder a: <drc at virtualized.org>
> Fecha: Thu, 30 Aug 2007 22:46:12 -0700
> Para: <jordi.palet at consulintel.es>, AfriNIC Resource Policy Discussion List
> <rpd at afrinic.net>
> Asunto: Re: [AfriNIC-rpd] Do we push for more V4 or advocate dual stack ??
> 
> Jordi,
> 
> On Aug 30, 2007, at 10:16 PM, JORDI PALET MARTINEZ wrote:
>> For running dual-stack, you don't need public IPv4 addresses.
> 
> I thought that at a bare minimum, you needed public IPv4 addresses
> for the NAT gateways and any public facing IPv4 services.

That's the ideal situation, but not the only path.

Moreover, those IPv4 public addresses needed for the gateways are already
there, let's say in 99% of the cases. Of course, if a new ISP come into the
game after the IPv4 exhaustion, they may not have *ANY* IPv4 address. I
doubt this could be the case, but even in that case, they will buy transit,
and the transit provider, as part of the service, will need to offer them a
few public IPv4 addresses enough for the gateways.

Anyway, I don't think we are going to be in that situation, really. Is what
I called the "very-critical-phase" in my document
(http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004).

> 
>> Regarding the 2nd hand equipment. If you have equipment that don't
>> run IPv6,
>> it should be so old (more than 5-6 years) that it is not reliable.
>> I really
>> thing that's a mistake in any network, as you can't provide a good
>> service,
>> so customers are unsatisfied and will move sooner or later to other
>> providers.
> 
> In the ideal world, everyone would run with the latest gear.
> However, pragmatically speaking and as you might have seen on NANOG
> regarding discussions about MSFC2s and Cisco 7600 series routers, few
> of us live in the ideal world.
> 
> The reality is that there is old gear out there that can't be
> upgraded for one reason or another.  This will continue to be the
> case.  A prudent course of action would be for folks to take an
> inventory of their equipment and software systems and perform triage
> (http://en.wikipedia.org/wiki/Triage) to figure out what's hopeless,
> what can be fixed, and what is OK.  Once this is done, people can get
> an idea of what they're in store for when IPv4 address space is no
> longer available via traditional means.

Yes, I can see that situation, but not a barrier that you can't sort out.

In the initial stage of the deployment, you don't need high performance
(hardware support for IPv6), so even in the case of an ISP that can't
support IPv6 in ANY of their actual boxes, which I really doubt may be the
case, you can always run IPv6 from a PC with Linux, BSD, etc.

I don't really think this should be a barrier. We shouldn't advocate for an
overnight deployment, but for an incremental one, which may mean running
IPv6 initially from a single box in the network, even if it is only
transition traffic.

This is already happening today since transition mechanisms such as Teredo
and 6to4 are coming enable by default. The difference is only to have some
control over the Teredo and 6to4 deployment by using reles at the ISP
instead of somewhere else that you can't control.

> 
>> Moreover, those 2nd hand routers are also incapable, for example,
>> of using
>> 224/8,
> 
> ?  Do you mean 240/4?

Yes, sorry, just landed from a long trip and I guess some cables got crossed
in my brain :-)

> 
> Regards,
> -drc
> 




**********************************************
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.






More information about the RPD mailing list