multiple prefixes

Brian E Carpenter brian.e.carpenter at
Wed Feb 13 14:32:33 CET 2013

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.


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: at [mailto:ipv6-ops-
>> at] On Behalf Of Brian E Carpenter
>> Sent: Wednesday, February 13, 2013 3:15 AM
>> To: Matthew Huff
>> Cc: 'Tore Anderson'; 'ipv6-ops at'; '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:
>>    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: at [mailto:ipv6-ops-
>>>> at] On Behalf Of Tore Anderson
>>>> Sent: Tuesday, February 12, 2013 12:41 PM
>>>> To: David Barak
>>>> Cc: ipv6-ops at
>>>> Subject: Re: multiple prefixes
>>>> * David Barak
>>>>> --- On Tue, 2/12/13, Tore Anderson <tore at> 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

More information about the ipv6-ops mailing list