multiple prefixes

[Brian E Carpenter]

Matthew, I suspect that we are violently agreeing. NAT-haters are a distinct
breed from firewall-haters, to oversimplify somewhat. Unfortunately the
two arguments tend to get mixed up.

   Brian

On 13/02/2013 13:21, Matthew Huff wrote:
> 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
>