[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
Hi Brian,
No at the time being. May be in the future, if there are interoperable
implementations ;-)
But my feeling is that it can be done in a much more simply way. Actually in
our case all the users in the 5.000 sites are already "authenticated" so
that will fall in the scope of the zeroconfiguration tunneling protocol that
has been submitted yesterday to the ID editor. I will upload it somewhere
else in case is not published already.
Regards,
Jordi
> De: Brian E Carpenter <brc@zurich.ibm.com>
> Organización: IBM
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Wed, 20 Oct 2004 16:08:28 +0200
> Para: jordi.palet@consulintel.es
> CC: v6ops@ops.ietf.org
> Asunto: Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
> Jordi, are you using ayiya for this deployment? If so, what's
> your experience?
>
> Brian
>
> JORDI PALET MARTINEZ wrote:
>> Hi,
>>
>> Agree, is better to heard the people that is doing that.
>>
>> Probably I'm one of those ;-)
>>
>> We are deploying networks for 5.000 IPv6 sites (not a joke !). At the time
>> being dual stack, but the aim in a short term is to disable IPv4 from the
>> access and core network.
>>
>> As today we need still dual stack in the hosts because there may be some
>> specific applications that could still be only IPv4, it seems to us that
>> NAT-PT is a bad solution, as probably will fail for those applications,
>> unless they are the typical HTTP applications, and in that case, we don't
>> need NAT-PT (it can be done with a much more simple proxy !).
>>
>> So looking for simplicity, we use a proxy for all the "old" IPv4 traffic, so
>> in our network (core and access) we only see IPv6 as much as possible.
>>
>> Alternatively for those applications that are still not ported, we use an
>> automatic 4in6 tunneling mechanism from the "client" to the other host (if
>> is located inside of our network), or from the client to the "border" of our
>> network (the point where we connect to Internet), if the other host is
>> located outside our network.
>>
>> DSTM may be a good candidate.
>>
>> I only see NAT-PT useful if the host can't be upgraded to IPv6 (dual stack
>> actually) and the translation is simple and don't break anything, which may
>> be easy because old IPv4-only devices should not use non-translatable header
>> fields, BUT may be not the case also ;-)
>>
>> A very convenient alternative could be that the 4in6 tunneling for those
>> devices is done by the border device (IPv6 router of the network ?). I think
>> this will alleviate any need for NAT-PT. I'm missing any possible scenario
>> where this couldn't work ?
>>
>> Regards,
>> Jordi
>>
>>
>>
>>> De: "Soininen Jonne (Nokia-NET/Helsinki)" <jonne.soininen@nokia.com>
>>> Responder a: owner-v6ops@ops.ietf.org
>>> Fecha: Wed, 20 Oct 2004 11:37:27 +0300
>>> Para: "'V6OPS'" <v6ops@ops.ietf.org>
>>> Asunto: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>>>
>>> Hello,
>>>
>>> in Asia there seem to be emerging _large_ IPv6 only networks that may
>>> need some connectivity to the IPv4 Internet. Example of these is for
>>> instance is CNGI. They have been extensively looking for a NAT-PT type
>>> solution and are considering to use NAT-PT. I think we should have some
>>> sort of proposal what to do if we decide that NAT-PT is not the way to
>>> go.
>>>
>>> I wish the people that are involved in these projects would speak up and
>>> explain their requirements.
>>>
>>> Cheers,
>>>
>>> Jonne.
>>>
>>> On Fri, 2004-10-15 at 16:46, ext Tim Chown wrote:
>>>
>>>> Soohong Daniel Park wrote:
>>>>
>>>>> Nevertheless, I know several sites are using NAT-PT efficiently on
>>>>> their use cases.
>>>>
>>>> It would be interesting, with the enterprise analysis in mind, to know
>>>> why these sites used NAT-PT, and what they could not solve in other ways.
>>>>
>>>> We used to run NAT-PT, but no longer do.
>>>>
>>>> As Pekka points out, we should also consider how IPv4 and IPv6 will be
>>>> adopted. IPv4 may remain the protocol to access legacy apps (like web,
>>>> mail, ftp). But these are also the ones that lend themselves to natural
>>>> proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :).
>>>> IPv6 may become more popular for specific new applications, which do not
>>>> require access to IPv4 services, as Pekka is hinting.
>>>>
>>>> Suresh wrote:
>>>>
>>>>> As Senthil points out, the assumption that NAT-PT deployment will stifle
>>>>> innovation in v6 seems flawed. NAT-PT is a transition mechanism which is
>>>>> essential for wider V6 deployment. Without NAT-PT, you will see bigger
>>>>> resistance to deploying V6 . You need NAT-PT for legacy applications (ex:
>>>>> e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts
>>>>> or
>>>>> applications. This is the attraction of NAT-PT. This is not the same as
>>>>> the
>>>>> proxy solution that will require applications to be changed/recompiled.
>>>>
>>>> Proxies can be deployed transparently. SMTP naturally so, Web caches also,
>>>> there doesn't necessarily have to be any client side alterations.
>>>>
>>>> Tim
>>>
>>> --
>>> Jonne Soininen
>>> Nokia
>>>
>>> Tel: +358 40 527 46 34
>>> E-mail: jonne.soininen@nokia.com
>>>
>>>
>>
>>
>>
>>
>> **********************************
>> Madrid 2003 Global IPv6 Summit
>> Presentations and videos on line at:
>> http://www.ipv6-es.com
>>
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be aware
>> that any disclosure, copying, distribution or use of the contents of this
>> information, including attached files, is prohibited.
>>
>>
>>
>>
>
>
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.