On Wed, 2004-05-05 at 16:34, JORDI PALET MARTINEZ wrote: > Hi Florent, > > I believe that asking the customer to do so is, in the majority of the > cases too much. While doing it automatically is very simple and the > extra work on the client side implementation pays for the value added. > In the worst case it should be an implementation issue (so a SHOULD > ?), and the market will decide with product is best ;-) Florent mentioned that user-side-configuration is optional, that is why he mentioned the 'wildcard encapsulation'. > ----- Original Message ----- > From: "Florent Parent" <Florent.Parent@hexago.com> > > I think we should keep this simple (no ip-proto 41 fowarding detection). > > Instead, the end-user can optionally select how the tunnel is established: > > > > By default, client requests a "wildcard" encapsulation (NAT detection > > enabled): > > - If no-NAT, proto 41 is used > > - If NAT, IPv6 over UDP is used > > > > The client can also be configured to request a specific encapsulation (NAT > > detection is off): > > - If the user knows that its NAT supports proto41 forwarding, then request > > proto 41 tunneling. > > - The client can also request IPv6 in UDP tunneling, no matter in which > > environment it is. This may be the case where the overhead is considered > > insignificant To rephrase: The configuration protocol can easily see if it is a NAT or not. Clients MAY request ANY, UDP or Proto-41 as encaps. When the encaps is ANY the client sends the IP it think it has globally to the configuration server, which compares it with the actual connection origin, different -> NAT -> use UDP. Otherwise it can safely assume proto-41. Additionally: Clients MAY also check if they have an RFC1918 address, they then also know that they are behind a NAT. Greets, Jeroen
Attachment:
signature.asc
Description: This is a digitally signed message part