Re: [Softwires] [Fwd: I-D Action:draft-carpenter-softwire-sample-00.txt]

[Rémi Després <[e-mail]>]

Le 10 juin 2010 à 16:19, Lee, Yiu a écrit :

> 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?

This should IMHO be very valuable for IPv6 usage to rapidly spread.
Early references include:
- sec 3.1.1 of draft-despres-softwitre-sam-00
- slides on 6rdE presented in Anaheim (www.ietf.org/proceedings/77/slides/v6ops-3)

> 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.

Indeed, and more precisely to introduce "native" IPv6.
("Native" addresses start with prefixes belonging to ISPs that assign them. IPv6 connectivity, and QoS, can thus be better guaranteed than with other addresses, those of Teredo in particular.)

> If the answer is YES. Then we can work on the technology.

I plan to have another draft for Maastricht, with some alternative choices to those of Brian and Sheng.

Regards,
RD


> 
> Regards,
> Yiu
> 
> 
> On 6/10/10 3:16 AM, "Brian E Carpenter" <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires