On Wed, June 9, 2010 11:27, Brian E Carpenter wrote:
> On 2010-06-08 23:30, Konrad Rosenbaum wrote:
>> On Mon, June 7, 2010 09:41, Brian E Carpenter wrote:
>>> This is another approach to stateless tunnels across subscriber NATs.
>>
>> There is of course the big question of how to discover a SAMPLE server.
>> I
>> doubt they would get any use if the user needed to enter anything in
>> his/her configuration.
>
> Well, that depends on the customer, but in general I think it needs to be
> a one-click operation.
Actually, for Joe-Average-User it should be zero-click. Teredo only gets
used because it is on per default and requires no configuration
whatsoever.
> At the moment we say
>
> "The SAMPLE interface in the host MUST be configured with the IPv4
> address and UDP listener port number of the SAMPLE server."
>From the users perspective this makes it more complicated than Teredo.
>From an implementers perspective it makes yet another tunnel protocol.
Only from a network and security perspective it has some limited merit,
since it is somewhat simpler than teredo.
> There are various ways of automating that, so maybe we can defer the
> discussion until we know whether the method is useful.
It is in my opinion useful, but only because it is simpler. The real
benefit will only show up once the discovery method is clear.
[cut]
>> Maybe a centralized registry?
>
> Or SLP. Or an IPv4 DHCP option.
Neither is very useful, since they are both designed to work on the LAN.
We need a protocol that can easily cross the NAT box without changing it.
So:
* no multicast (SLP)
* no broadcast (DHCPv4)
* no use of private addresses as target IP
* no DNS magic(*)(**)
(*)some NATs drop what they call "unknown query type" packets
(**)some users use alternative DNS servers as forwarders, which means any
heuristic to find out where you are will fail for them
That leaves either a very simple request via TCP or via UDP - maybe as
some kind of directory lookup.
>> Also I would change the address format:
[cut]
> Well, the draft uses as closely as possible the Teredo format. Also
> we need to respect the u/g bit, which in your proposal means stuffing
> 2 bits into the V4ADDR field (more comments below). I'm not sure this
> is worthwhile to avoid hairpinning.
I see.
Konrad
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
