Brian, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Brian E Carpenter > Sent: Thursday, June 10, 2010 12:17 AM > To: Konrad Rosenbaum > Cc: [email protected] > Subject: Re: [Softwires] [Fwd: > I-DAction:draft-carpenter-softwire-sample-00.txt] > > 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.
SAMPLE server discovery seems analogous to ISATAP router discovery. One method is to resolve a FQDN to get back a list of IPv4 addresses of SAMPLE servers. The FQDN could be delivered to the SAMPLE host when it does the initial download of the SAMPLE tunnel software, then the host can periodically (re)resolve the FQDN to get a list of IPv4 addresses of nearby SAMPLE servers. To the draft p.6 comment about keepalive probes, why not just send periodic RSs to get RAs back the same as is done for ISATAP? Fred [email protected] > 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
