Konrad, > 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.
Maybe, but isn't the first question whether this approach is preferable to either a full SAM implementation, or to draft-lee-softwire-6rd-udp? I'm pretty confident a discovery method can be devised. Regards Brian On 2010-06-10 01:01, Konrad Rosenbaum wrote: > 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
