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

From: Rick van Rein <[email-masked]>
Date: Wed, 27 Jul 2011 11:40:38 +0000

Hello Washam,

Thanks for commenting on my 6bed4 proposal.

> For first glance, i have a rough impression this draft has some
> similarity with another draft written a while ago at least in terms of
> udp encapsulation of ipv6. please refer to
> http://tools.ietf.org/html/draft-lee-softwire-6rd-udp

I will look it up.  Packing it up in UDP is commonly done, and has
shown to make a tunnel independent of the router used.  AICCU in
the SIXXS project does it too, for instance.  And so does TSP from
RFC 5572.

What 6bed4 does different, is employ autoconfiguration to get an
IPv6 address from a remote tunnel server.

> 1. fe80::/128 seems to me a subnet router anycast address according to
> section 2.6.1, rfc4291. so you should not consider it as a unicast
> address. although, i dont see any issues under the circumstances.

I was not aware that the router address was an anycast address,
but you are right.  Strictly speaking it is routed to precisely
one router using the underlying IPv4 address.

I wonder if it can be called an improper implementation to have an
anycast addresses on a pointopoint link?

> 2. you use DiffServ field several times, do you actually mean
> TrafficClass field? please in line with rfc2460.

Yes, that is what I meant.  I have fixed it for -01, thanks.

Has this ever been renamed in IPv4, or is it still officially called
Type Of Service?

> 3. why don't you mention direct encapsulated ipv6 end embeded system
> to end embeded communication? is it not in your senario or anything
> else?

I have difficulties parsing this one...

I mentioned peer-to-peer traffic in 2.2; encapsulating IPv6 in IPv4
(proto-41) is not independent of the router used; is that what you
were asking about?

> 4. you seem omit MTU and fragment/reassembly discussion.

Good point, thanks.

Thanks,
 -Rick

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 27 Jul 2011 14:11:06 +0200

> the SIXXS project does it too, for instance.  And so does TSP from

AICCU is a tool, the protocol that you mean is AYIYA.

Teredo, which is mostly stateless and already deploy would fit your
requirements quite well, especially as you are only connecting a single
host.

As your main 'requirement' is embedded system, you might want to look at
6lowpan and of course simple native IPv6.

But I really wonder why you mention that 'embedded' is so special while
having both a full IPv4 and IPv6 stack in it is actually the heaviest
portion you can have. Stripping the IPv4 stack would serve your purpose
much better.

Also if there is no native IPv6, then let an external device do the IPv6
gatewaying to the Internet.

Also you are forgetting about a VERY important aspect that Teredo does
solve: local traffic between hosts.

As your made-up global IPv6 address is based on the outmost IPv4-NAT IP
address + port (because otherwise the PoP would have to keep state), I
really wonder how you stick that address as a source address in the IPv6
header that is inside the IPv4 packet.

I can only suggest that you look at Teredo which solves most of these
issues with autoconfiguration and not state. Teredo matches most of your
'requirements'...

Greets,
 Jeroen

---

From: Rick van Rein <[email-masked]>
Date: Wed, 27 Jul 2011 12:51:14 +0000

Hello Jeroen,

Thanks.  Not all my answers are technical, but they also relate

> requirements quite well, especially as you are only connecting a single

Teredo does not keep the address space transparent; peer-to-peer
connectivity is just as much a problem with Teredo as with IPv4.

One application area that I want to see moving towards IPv6 is
SIP (and I am working hard on that) and Teredo is not suitable
for that application -- traffic would still need to pass through
an RTP proxy under the limiting control of a provider.

My work on SIP over IPv6 is the background of 6bed4, which I have
generalised to what I think is a good option for IPv6 acceptance
in embedded devices in general.

To free SIP from the trouble that NAT causes (not firewalls, but
the translation side of NAT) it should be IPv6-only.  With that
in place, reliable over-the-internet connection mechanisms are
possible without intervention of a service provider whose RTP
proxy won't connect anything but (say) voice, or who is not
willing to support a deaf man's realtimetext session.

> 6lowpan and of course simple native IPv6.

With 6lowpan, there would be no support for general (ether)networks.

Native IPv6 rocks (even more than your SIXXS tunnels) and I have it :)
but this is not an assumption that a device manufacturer can rely on,
so the support of IPv6 feels like an added frivolity to them.

> portion you can have. Stripping the IPv4 stack would serve your purpose

I kept these things a bit general in the draft, but walk up to your
local gadget store and you will see no support for IPv6 to match the
support found in operating systems.

Programming a dual-stack system means that your code cannot make
an implicit assumption throughout that it is a single-stack system.
Or, if it does, it may step up to IPv6 if it can at the same time
drop IPv4.  Even mature open source networking tools contain this
assumption; embedded environments are even more likely places for
short-cuts like these, and so these are very hard platforms to get
to become dual-stack.  If it is hard, and it does not bring any
new sales, then why go for dual-stack devices?

> gatewaying to the Internet.

The academic in me agrees.   But it is very hard to sell to everyday
customers, and device manufacturers would not take that leap.

> solve: local traffic between hosts.

Thanks, this is indeed not the connectivity I was concerned about.
Good point, need to think it over.

> header that is inside the IPv4 packet.

The first thing done is autoconfiguration, with the tunnel server as
a target.  The tunnel server can find this information in the IPv4
header that it receives.

> issues with autoconfiguration and not state. Teredo matches most of your

Except for a transparant IPv6 address space!

Thanks,
 -Rick

---

From: Washam Fan <[email-masked]>
Date: Thu, 28 Jul 2011 10:48:00 +0800

Hi Rick,

Please see inline.

> (proto-41) is not independent of the router used; is that what you

I was referring to section 4.3. it seems to me all internal ipv6
traffic U-turn the tunnel server. How about 'direct' tunnelled between
2 embeded hosts without going thru the tunnel server? if it is
applicable, it would mitigate the burden of the server and the
possibility of a single point failure.

Thanks,
washam

---

From: Rick van Rein <[email-masked]>
Date: Thu, 28 Jul 2011 08:56:58 +0000

Hi,

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

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.

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

If you are saying that I over-generalised by speaking of "embedded
systems" instead of a tighter area, and that Teredo may work for
certain embedded systems then I agree.

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

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

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:[email-masked]

> Are you talking about "embedded devices" as in "8kb memory" or "embedded
> devices" which are actually full blown Linux boxes?

Sort of in between -- 128-ish kB RAM.

> For instance the Gigaset S675IP and related boxes running their Chagall
> firmware are a good example [...]

Indeed.  But there are also examples that do cannot run fullblown Linux
but that do networking.  I am getting a simple SIP app running in about
64 kB of code, and a few kB of RAM.  With IPv6 on any network, thanks
to 6bed4.  IPv6 may turn out to be a way to rely on cheaper hardware ;-)

> You stated 'embedded' and thus I think of 8kB memory and low-resources
> available. If you have resources then doing any of the currently
> available tunneling protocols should work like a charm.

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.

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

> Your requirements section just lists the features that your protocol
> has, not why that requirement is important for you to solve and for what
> purposes.

Ah, hence the quotes around 'requirements'.  Fair enough, although the
requirements really did come up as requirements.  I hope the above helps.

I am thinking that the requirements might be better dropped from the
draft, but felt a need to describe, in general terms, what I was
looking for and why yet another tunnel was IMHO needed.  I am starting
to feel that it might be better to just stick to the technology.

> Another option is to do what we call pre-configured AYIYA tunnels. In
> the cases where we deployed these they where vendor-bound though and
> thus effectively took care of the problem of getting IPv6 packets to the
> vendors servers, thus avoiding the need for IPv4 as everything was just
> IPv6 (except for the tunnel).

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

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?

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

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

Best wishes,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Thu, 28 Jul 2011 08:58:24 +0000

Hello,

> possibility of a single point failure.

Jeroen also raised this, and I have overlooked it in the tunnel
design.  I will need to think it over.  It is a very good point.

-Rick

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 28 Jul 2011 11:32:07 +0200

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

>    - Teredo service will not work through NATs of the symmetric variety.

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

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

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

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

> for locating phones: ENUM, freenum.org, sip:[email-masked]

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

[..]
> 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...)

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

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

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

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

> Java applet that we are maing to connect IPv6-only from an IPv4-only

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

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 28 Jul 2011 08:04:17 -0700

> SIP telephony, IPv6-only, no end user configuration of IPv6.

Generally solved with a sip b2bua or SBC that terminates one call leg on v6
and the other on v4.

You will see this commonly in VoLTE which is SIP on mobile phones.

Cb

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops