Re: [nat66] MAP66

[Tomas Podermanski <[e-mail]>]

Brian,
    the current version of map66 implements only
draft-mrw-behave-nat66-02 (as you can see
http://map66.svn.sourceforge.net/viewvc/map66/README.txt?revision=55&view=markup)
. Unfortunately the project haven't been touched for more than 4 months.
I Don't know if the author have any plans to maintain the project in the
future. That is the reason why we are thinking of reimplementing the
code. We have several customers that are very interested in NPTv6 and
map66 is only implementation we have found so far.

Regards
    Tomas

On 3/4/11 8:27 PM, Brian E Carpenter wrote:
> Tomas,
>
> Thanks. Does this exactly implement draft-mrw-nat66-09.txt?
>
> It would be better to refer to NPTv6 not NAT66, I think.
>
> Regards
>    Brian Carpenter
>
>
>
>
> On 2011-03-04 20:10, Tomas Podermanski wrote:
>> On 3/3/11 8:48 PM, Brian E Carpenter wrote:
>>> On 2011-03-03 19:51, S.P.Zeidler wrote:
>>>> Thus wrote Brian E Carpenter ([e-mail]):
>>>>
>>>>> On 2011-03-03 10:49, S.P.Zeidler wrote:
>>>>>> Thus wrote Brian E Carpenter ([e-mail]):
>>>>>>
>>>>>>> On 2011-03-03 09:30, S.P.Zeidler wrote:
>>>>>>> ...
>>>>>>>> Which applications will have trouble with address stability and
>>>>>>>> provider independence, thus requiring you to make the benefits of NPTv6
>>>>>>>> line up with the applications you want to use??
>>>>>>> The usual ones - those that for whatever reason have explicit
>>>>>>> dependency on the IP address of the peer.
>>>>>> i.e. they will have trouble with PI addresses also?
>>>>> No, why?
>>>> I am trying to point out that you (and the draft) are claiming that.
>>>>
>>>> The benefit of NPTv6 is address stability and provider independence.
>>>> The benefit of PI is address stability and provider independence.
>>>>
>>>> The cost of the method NPTv6 applies to get that benefit is that the
>>>> addresses change in flight. -This- is the issue.
>>>>
>>>> The benefit does not cause any trouble.
>>>> The means by which you reach this benefit may.
>>>>
>>>> You see the distinction?
>>> Of course. PI has the cost of exploding the BGP4 table.
>>> NPTv6 has the cost of destroying address transparency.
>>>
>>> Since SHIM6 has neither of these costs, are you surprised
>>> that I prefer it?
>>>
>> I completely agree with you. SHIM6 is definitely better solution than
>> MAP66. But the problem is that SHIM66 requires support for both server
>> and client side. Living in the real world we can not expect that SHIM66
>> will be widely supported in less than 5 or 10 years. SHIM66 is nice and
>> great solution but not for today.
>>
>> MAP66 is a pragmatic solution that can work today (working
>> implementation of map66 exists - http://map66.sourceforge.net/). Beleive
>> me, there is really huge demand from enterprise to have solution like
>> MAP66. MAP66 is easy to understand, easy to implement, follows habits
>> that people are used to using in IPv4 world and can work immediately.
>>
>> >From application perspective, address rewriting used by MAP66 is not a
>> new issue. The technique is used by enterprise to mapping public
>> addresses to DMZ for many ears. Almost all application had to deal with
>> it somehow.
>>
>> Tomas
>>
>> _______________________________________________
>> nat66 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nat66
>>