multiple prefixes

[Matthew Huff]

Tore,

Do you know of any knowledge base of mainstream commercial network equipment (routers, switches, firewalls, load balancers, etc...)
that supports NPTv6? There seems to be very few equipment on the market currently that supports NPTv6.


IMHO, the push to force end-to-end connectivity (no-nat) that pervades the IPv6 community has slowed the growth of IPv6
considerably. There are a lot of corporate entities (us included) that have no interest in having p2p connectivity. In fact, we do
everything possible to block it and will continue to do so in IPv6. Imagine if there were wide support for some sort of NAT46
solution so that internal networks could stay ipv4 but have ipv6 connectivity while they slowly migrate to ipv6. Perhaps they would
never move internally from ipv4, but externally they could be 100% ipv6. This would be fine with the vast majority of corporate
networks. 

FYI, we have a PI IPv6 address space and advertise it via BGP, and are slowly migrating internally to dual-stack systems. However,
we have run into a lot of application issues so far - mostly applications that don’t expect multi-homing and legacy equipment that
will never support ipv6.


----
Matthew Huff             | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039
aim: matthewbhuff        | Fax:   914-460-4139


> -----Original Message-----
> From: ipv6-ops-bounces+mhuff=ox.com at lists.cluenet.de [mailto:ipv6-ops-
> bounces+mhuff=ox.com at lists.cluenet.de] On Behalf Of Tore Anderson
> Sent: Tuesday, February 12, 2013 12:41 PM
> To: David Barak
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: multiple prefixes
> 
> * David Barak
> 
> > --- On Tue, 2/12/13, Tore Anderson <tore at fud.no> wrote:
> >
> >> You'll need [non-free] hardware to run the [free] software
> >> implementation on, even at a small scale.
> >
> > Many non-ISP organizations view hardware capital costs (i.e.
> > non-recurring) as vastly preferable to monthly recurring charges,
> > especially when the term length for the MRC is "forever", even if the
> > MRC is low.  Whether or not this is a good idea is a separate
> > question, but it's a well-known behavior of many in the enterprise
> > world.
> 
> Sure. But hardware also comes with recurring charges. Electricity,
> hosting, support contracts, sysadmin hours, and so forth.
> 
> > I do think the attitude presented by many of the folks who encourage
> > IPv6 adoption is not conducive to getting the enterprises to adopt v6
> > - we as a community come across as dismissive of the level of effort
> > required for the enterprises to learn a whole new way of doing things
> > for benefits which are neither obvious not quantifiable in the
> > near-term.  Modifying our tone and presentation, and spending more
> > time listening to the concerns of the enterprise IT folks, would be
> > worth it.
> 
> I like facts. If someone has considered the facts, and concluded that
> NPTv6 is the best approach for them, then great, that's what they should
> be using. Same thing goes for PI or PA or anything else.
> 
> My domain name notwithstanding, I don't like FUD. FUD may lead folks to
> make the wrong decisions, and that's certainly not, to borrow your
> words, conducive to getting the enterprises to adopt v6.
> 
> So. Some facts:
> 
> - NPTv6 isn't free. It might be cheap, or expensive. It Depends.
> - PI isn't free. In the RIPE region, it's cheap.
> - NPTv6 has adverse effects on certain applications.
> - PI doesn't cause any application breakage.
> - NPTv6 doesn't cause DFZ growth.
> - PI causes DFZ growth.
> - PI doesn't require the end user to run BGP.
> - PI and NPTv6 aren't even mutually exclusive.
> 
> Best regards,
> --
> Tore Anderson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5339 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130212/e3fe3d2e/attachment.bin>