Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00

[Jeroen Massar <[e-mail]>]

On 2011-07-28 10:56 , Rick van Rein wrote:
> Hi,
> 
>>> Teredo does not keep the address space transparent; peer-to-peer
>>> connectivity is just as much a problem with Teredo as with IPv4.
>>
>> Can you elaborate on what you actually mean with this and what the
>> problems are? Especially how you try to resolve them with your proposal?
> 
> 1. Personal experience with Teredo: ping time variations, failure
>    to route to certain IPv6 ranges.

That is because you are using a service of which you don't know where it
is (and anycast on both IPv4 and IPv6 means you will have routing
difference/guesses in both IPv4 and IPv6) and maybe that the service
provider has some bad/missing routes.

Like every other thing you will have to contact the operator to resolve
these. Which is tough as you can't directly see where the traffic is
flowing over IPv4+IPv6 and maybe it is the route back that is the problem.


> 2. Teredo is not a general solution -- and it won't help the SIP
>    wish that I am developing for.  From RFC 4380 section 8.3:
> 
>    - Teredo service will not work through NATs of the symmetric variety.

Which apparently is only a couple of percent of the internet.

>    - Teredo introduces jitter into the IPv6 service it provides, due to
>      the queuing of packets while bubble exchanges take place.  This
>      jitter can negatively impact applications, particularly latency
>      sensitive ones, such as Voice over IP (VoIP).

Those bubbles are only sent at the beginning after that rarely and
should not impact your RTP streams too much.

> But specifically for SIP, I still have not found an existing zeroconfig
> tunnel service that can do the job.

SIP should do fine, RTP is what you mean. As for Zeroconfig, well TSP
can do the trick for that as Gogo6 does anonymous tunnels.

>> Where exactly does a "RTP proxy" come into play unless you are
>> translating from IPv4 to IPv6 and vice versa?
> 
> I did make a translator between SIP over IPv4 and SIP over IPv6, but that
> is not what I meant.  (Link: http://devel.0cpm.org/sipproxy64/)
> 
> An RTP proxy is needed as a general solution to connect phones behind
> NAT.  To open a hole for RTP in a firewall, traffic must be sent out.
> At that point, the address translation is also set.  The same applies
> to the other side, so neither can start the transmission as the remote
> address is not known.  This is specifically a problem to symmetric
> NAT, which means that to be general you will need a server at a fixed
> IP that bounces RTP back and forth, known as an RTP proxy.

Ever heard of this awesome protocol called STUN which where made by the
IETF for this? And TURN and then we have NAT-PMP and uPNP which is
implemented in almost any CPE.

> Needing an RTP proxy means to most users that they become dependent on
> service providers, who prefer to sell you bit-stuffed POTS connections.  
> If you don't need an RTP proxy, you can embrace Internet-style schemes
> for locating phones: ENUM, freenum.org, sip:[e-mail]

The solution to your problem is:
 - get a public IPv4/IPv6 address
 - done

I don't see end-user without technical knowhow do this kind of setup,
generally they want

[..]
> I investigated every single tunnel that I could find, but none works
> for the application area I have in mind.  One thing I wish to avoid
> is asking end users to configure accounts.

TSP anonymous does not do that. But the fun thing is instead of asking
people to create accounts you ask ISPs soon to all start adding your new
thing which does not add anything new? :)

(And creating a security nightmare...)

>> It completely depends on what your deployment model is though and the
>> actual problems you are trying to solve.
> 
> SIP telephony, IPv6-only, no end user configuration of IPv6.

Upgrade CPE to one which supports IPv6 (be it native or tunneling),
presto. The user will upgrade to IPv6 at one point or another anyway.

> Is there a place where I can read more about pre-configured AYIYA?
> Neither Ecosia nor Google has heard of it.

AYIYA is just the tunnel protocol. Pre-configured means that one can
skip the TIC step as the parameters are already present that TIC would
otherwise fetch.

> Could such a setup be pre-configured into a device and then shipped
> off to customers, and could that not lead to non-local tunnel service
> and potential abuse of an account?

If people are able to get into the firmware and figure out the AYIYA
password, then yes of course they can then use that tunnel for other
purposes than intended. But as it is known where that account is
disabling it is also very easy.


>> As they all simply use NAT-PMP/uPNP to overcome the issue of IPv4 NAT.
>> That only works with a single layer of NAT but that is what is generally
>> the case.
> 
> Need to dig more into this.  Not sure why I don't see phones and
> SIP providers relying on this (for their RTP connections).

Gigaset understands this really well ;)
http://s-a.no/tmp/GizmoGigaset.gif for a little screenshot
(googleimages(gigaset STUN))

And I expect most other providers to do the same.

And they could easily do a "dear NAT-PMP/uPNP" please forward all port
5060 packets to me and then also be a full blown SIP server.


>> See the above vendor-specific AYIYA support. That works like a charm.
> 
> Could pre-configured AYIYA be part of the open source SIP firmware
> for IPv6-only that I am developing?  And could it be configured into the
> Java applet that we are maing to connect IPv6-only from an IPv4-only
> browser environment?

As it is a protocol you can develop it in any language that you like. I
don't really see how you can mix embedded and Java and low latency in
the same message though....

Greets,
 Jeroen