multiple prefixes

[Matthew Huff]

I never said that NAT nor NPTv6 is needed for protection, merely that many ipv6 proponents have a strong anti-nat (or anything that smacks of nat like NPTv6) belief because they want to restore end to end connectivity. I stated that end-to-end connectivity isn't something most business networks care or want, not that NAT or NPTv6 is needed to block p2p.


----
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 Brian E Carpenter
> Sent: Wednesday, February 13, 2013 3:15 AM
> To: Matthew Huff
> Cc: 'Tore Anderson'; 'ipv6-ops at lists.cluenet.de'; 'David Barak'
> Subject: Re: multiple prefixes
> 
> Matthew,
> 
> On 12/02/2013 18:00, Matthew Huff wrote:
> > 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.
> 
> Indeed. I hate to repeat myself, but that's *exactly* why we wrote RFC4864.
> Neither NAT66 nor NPTv6 are necessary for protection. There is a case for
> NPTv6 for multihoming, but there's also a case against it in the RFC queue:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/
> 
>    Brian
> 
> > 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/20130213/190de76a/attachment.bin>