In your previous mail you wrote:
The UDP tunneling scenario aims at solving the NAT crossing problem.
=> I'd like to say IPv6 over UDP is useful in other cases but I am afraid
that you are right: this is useful when there is a NAT or a firewall or
both.
This is fine, but we need more than just a port number and a payload
format to make this work.
=> this covers some cases so this is perhaps not enough but still useful
(port number: to be allocated by IANA, payload format: one IPv6 packet ==
one UDP packet).
Since the origin of the tunnel is located
behind a NAT, and possibly many, you cannot predict the port number and
the IP address that it will use. Also, it is fair to assume that the
tunnel will probably not be offered by the local ISP -- if this ISP
wished to provide IPv6 service, it could just enable native IPv6, or
possibly native tunneling.
=> there are two common cases where we aren't hurt by this issue:
- there is only one NAT and it is locally managed
- the ISP filters out "unknown" protocols (including 41)
I think we must meet the following requirements:
1) There is no way to "pre-configure" the connection. The association
between a given "user prefix" and a pair of natted address and port must
be discovered in real-time.
=> a known port is still useful if NATs don't nat both source
and destination.
2) There must be a way to verify the identity of the party requesting
the tunnel, to mitigate the risk of traffic highjacking, and possibly to
ensure that only authorized parties are using the service.
3) There must be some way to verify the origin of the traffic, in order
to avoid denial of service attacks.
=> 2 and 3 have the same solution: some kind of IPsec... An option should
be something like [IPv4][UDP][ESP][IPv6]. I believe there are such things
in the IPsec mailing list for NAT tranversal.
4) There must be a way to "qualify" the tunnel, and check that traffic
is indeed flowing in both directions -- NAT configurations are prone to
bizarre cases of failure.
=> ah! IPv6 has already the right tool: NUD!
We should also note that IPv6 over UDP should be designed to work with
all NATs, including those that use "destination specific" port mappings.
=> I can't see the exact implication of this.
The design, and the port discovery, should be focused on bilateral
tunnels.
Thanks
[EMAIL PROTECTED]
PS (1): the idea is to send a magic packet to the destination
at the known port. If only the source is natted then the peer
address and port will be available in the encapsulated stuff.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
