[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-palet-v6ops-proto41-nat-00.txt
Hi Alain,
> -----Mensaje original-----
> De: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] En nombre de
> alain.ritoux@6wind.com
> Enviado el: lunes, 23 de junio de 2003 12:00
> Para: JORDI PALET MARTINEZ
> CC: v6ops@ops.ietf.org
> Asunto: Re: draft-palet-v6ops-proto41-nat-00.txt
>
>
> Hi,
>
> > Hi all,
> >
> > We just submitted a draft on usage of Protocol 41 over
> NAT boxes. >
>
> I have some question about this draft.
> You propose :
> v4 v4
> X ---- NAT-box ----- Tunnel Serveur -- v6 world
> * *
> *************************
> 6in4 tunnel
>
> 1) OK, but if the NAT-box dosen't support proto 41, it
> will need a firmware update. As to proceed with such an
> update wouldn't it be more safe, to have th NAT-box be
> IPv6 compliant, hence allowing
> dual v4
> X ---- NAT-box ----- Tunnel Serveur -- v6 world
> * *
> **************
> 6in4 tunnel
> hence removing the need for proto 41 support !
Yes, but adding support for 6in4 tunnels means adding IPv6 support to the
NAT box which is not a simple modification. On the contrary, adding proto 41
forwarding to a NAT implementation can be simple: most of the code is
already available and the box does not even need to know about IPv6.
> 2) in case of NAT-box wih proto 41 support, how does it
> work, when
> - several Host/routers want to have 6in4 tunnel towards the
> same tunnel serveur
> - the NAT-box a only ONE public address
> because proto 41 doesn't provide ports as in UDP/TCP or ID
> as in the ping, for additional multiplexing level.
Only one tunnel is allowed per public address and per tunnel server.
The main problem here is that the firts machine in the private network
sending IPv6 over Ipv4 traffic to the tunnel server will "catch" the proto
41 entry on the NAT table. Later trials from other machines will fail.
That is why it would be very useful to add a new command to NAT boxes in
order to define a default machine in the private network to receive proto 41
packets. This can be done at present for specific TCP/UDP ports or for all
ports, but not for specific protocols. In this way you will have the
flexibility to use different machines for external services (NAT entries for
www, mail, etc ports) and IPv6 tunnels (NAT entry for proto 41), as well as
avoiding other private machines to "steal" the proto 41 NAT entry.
> 3) do you have an estimation (like the one Christian
> Huitema gave in his NAT classification) about how may NAT
> support proto 41 and how many don't ?
Not yet. We have tested several NAT-routers but we do not have by now such
estimation nor the capacity to test a significant number of router
models/vendors. That is why Jordi sent a message to this list asking for
collaboration.
> 4) anyway, if there is a NAT we don't known about in the
> way and that does not support proto 41, all we can see is that
> eh! this tunnel doesn't work !!
You can make a simple test by sending and IPv6 over IPv4 packet to an
external test system (the tunnel broker for example). If it arrives, then
the NAT is capable of forwarding proto 41. It could also be tested in the
opposite direction. Anyway, this should be further investigated to see if it
is viable for common operating systems.
> don't you feel it to be risky for a tunnel broker to
> provide solution that don't work in some case, he can't
> even predict ?
As it seems no unique mechanism will be available to traverse NAT, tunnel
brokers could make a predifiened set of tests in order to evaluate which one
can be used (proto 41 forwarding, UDP, etc).
Best regards,
------------------------------------------------------------------
Dr. David Fernandez Cambronero
Associate Professor
Dpto. Ingeniería de Sistemas Telematicos
E.T.S.I. Telecomunicacion
Ciudad Universitaria
E-28040 MADRID
tel: +34 91 5495700 x.432
fax: +34 91 3367333
e-mail: david@dit.upm.es
------------------------------------------------------------------