I am also confident that the discovery method can be devised. However, I think the first question to the WG is:
Any interested in defining a stateless tunnel protocol that works behind legacy NATv4? The whole idea of defining this protocol is to provide a lightweight implementation to allow ISP to introduce v6 to their customers w/o upgrading the network and home gateway. If the answer is YES. Then we can work on the technology. Regards, Yiu On 6/10/10 3:16 AM, "Brian E Carpenter" <[email protected]> wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
