Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jul 2011 14:55:55 +1200

Rick,

Somebody suggested Teredo instead. The problem with Teredo is that it
uses a generic prefix and an anycast IPv4 address. Thus it has some
operational problems (less serious than 6to4, but still...).

A variant of Teredo that can use a provider-specific prefix and a
unicast IPv4 address would surely do for the embedded systems market.
But we haven't found enough interest in the IETF for that approach.

See draft-carpenter-softwire-sample-00.txt, draft-lee-softwire-6rd-udp-02.txt
and draft-despres-6a44-00.txt for the historic trail.

Regards
   Brian Carpenter

On 2011-07-26 00:01, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : IPv6 Tunneling for Embedded Systems (6bed4)
> 	Author(s)       : Rick van Rein
> 	Filename        : draft-vanrein-v6ops-6bed4-00.txt
> 	Pages           : 17
> 	Date            : 2011-07-25
> 
>    Given the limited resources available to a lot of embedded systems,
>    dual-stack solutions are not always feasible for such hosts.  A
>    mechanism that supports a direct transition from IPv4-only to
>    IPv6-only may prove beneficial in getting the smallest hosts to make
>    a transition to IPv6 at a much earlier stage than would otherwise be
>    possible.  This calls for tunnels, but no current tunnel technique
>    appears to be optimal for embedded systems.
> 
>    This specification details an IPv6 tunneling technique over UDP and
>    IPv4.  The technique is specifically designed to benefit embedded
>    systems, and to work without end user configuration.  The working
>    principle for obtaining a routable IPv6 address is through stateless
>    autoconfiguration from an anycast tunnel service.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-vanrein-v6ops-6bed4-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-vanrein-v6ops-6bed4-00.txt
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 28 Jul 2011 10:39:10 +0200

> But we haven't found enough interest in the IETF for that approach.

For those there is already TSP, which is already an RFC, AYIYA which I
might be redoing the draft for in a few weeks.

Greets,
 Jeroen

---

From: Rick van Rein <[email-masked]>
Date: Thu, 28 Jul 2011 09:04:38 +0000

Hi,

> might be redoing the draft for in a few weeks.

TSP has a number of problems:

* There is no open source server-side implementation; I started one, but
  moved over to 6bed4 because of the following shortcomings.

* Existing client implementations do not work according to the RFCs.

* Correcting those clients demonstrated that the available servers
  won't accept RFC-compliant traffic.

-Rick

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Jul 2011 11:13:44 +0200

Maybe I am missing something, but this protocol sounds a lot like 6to4 but
then on top of udp instead of protocol 41.

---

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

On 2011-07-28 11:04 , Rick van Rein wrote:
> * There is no open source server-side implementation;

That is really the problem of the person who wants to build it. There
are multiple implementations in use.

> I started one, but moved over to 6bed4 because of the following shortcomings.
> 

Maybe you should contact the programmers of the client and the operators
of the service about this? There must be a reason why they are different.

IPv6.org.sa / CITC apparently did their own implementation[1] of the
server side based on the RFCs and the standard gogo6 client works for
them... so are you sure you did not do something wrong?

They also state in those slides that they might open source the thing.

Greets,
 Jeroen

[1] Google docs/cache URL as their website is unreachable for me
a google(www.ipv6.org.sa) pops it up

https://docs.google.com/viewer?a=v&q=cache:iSgSvLpRDk8J:www.ipv6.org.sa/sites/default/files/CITC%2520IPv6%2520Tunnel%2520Broker%2520-%2520CITC.pdf+%22www.ipv6.org.sa%22&hl=en&gl=ch&pid=bl&srcid=ADGEEShkmEVwfkVJPXHgGkNjb1EavvadxA7C6RmkqCSm95ovr5oK-Cdyql6i0WsOOk024dJhFJSgWhVJ8kraB8WGpRdeffavGCKtHJ9BppZm9ajmHA_4x6PfSW8hOd7N-TIuc_mjPZkv&sig=AHIEtbTllhdinArwegu8bKsd1F2iAwJr0w

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Jul 2011 08:48:40 -0400

>operational problems (less serious than 6to4, but still...).

I am not sure that Teredo has less serious operational problems than 6to4, or whether Teredo's problems have often been masked by the preference of 6to4 over Teredo in hosts that implement both.  I keep hearing that Teredo performs significantly worse than 6to4.  (Though perhaps not for a provider managed Teredo variant like you have proposed.)

Keith

-- 
Sent from my Android tablet with K-9 Mail.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 28 Jul 2011 09:04:05 -0400

If you'd like to have a really slow, fairly unreliable experience teredo is a pretty good choice.

On Jul 28, 2011, at 8:48 AM, Keith Moore wrote:

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

---

From: "John Mann (ITS)" <[email-masked]>
Date: Fri, 29 Jul 2011 11:48:18 +1000

Hi,

> then on top of udp instead of protocol 41.

I was thinking that 6bed4 seems similar ISATAP, but with NAT traversal.
Nice in that a successful RS/RA exchange is required before the client
routes traffic through the tunnel.

- 6to4 client is a router, and gets a /48 out of a single global address
space
- 6rd client is a router, and gets a /48../64 out of its' 6rd-ISP -provided
address space
- Teredo client is an end-system that gets one IPv6 address from a single
global address space
- ISATAP client is an end-system that gets one IPv6 address from an
enterprise-defined subnet
- 6bed4 client is an end-system that gets one IPv6 address from a (global)
subnet selected by the tunnel server address/port
- tunnel-broker clients - varies, and I don't know the specifics

===
6rd gets its config from DHCPv4 option (or static config).
ISATAP chooses its gateway using DNS A lookup of "ISATAP" name (or static
config).

Could 6bed4 get its config from a DNS A or SRV lookup, instead of statically
defined?
Or DHCPv4 option since we are already doing DHCPv4 of address assignment --
probably not suitable for global deployment.

===
I would have requested two well-known UDP ports.
One for the tunnel destination, and also one for the client sending port.
Would make it easier to create ACL permits, and also avoid being blocked by
mistake.

===
I can think of a third profile - overlay.
Say a researcher wants to sprinkle webcams across Australia.
They will get Internet access via different ISPs, different NATs/CPEs,
different local admins etc etc
Choose a non-standard public IPv4 tunnel service addr/port from your
enterprise address space and configure into each webcam.
Choose a public or private IPv6 subnet for the gateway box.

This would be a "managed" service like 6rd rather than an un-managed service
depending upon the kindness/ability of strangers like 6to4 or Teredo.

But, I think I have just re-invented an un-encrypted VPN, or anonymous
tunnel-broker ...

I don't think we need 20 slightly-different IPv6 transition mechanisms.
It would be nice if we could filter/combine the options, and come up with a
short list of good options for a short list of use cases.

    John

---

From: Rick van Rein <[email-masked]>
Date: Fri, 29 Jul 2011 14:43:20 +0000

Guys,  (and girls?)

Thanks _very_ much for your feedback on the draft!

It's hardly possible to respond to everyone, so much has
been thrown my way!

I am reading it all, and processing it.  Based on plain Neighbour
Discovery, I seem to have found a way to resolve not only local
routing shortcuts, but even direct connections between IPv4
routers with cooperative NAT.  I am working that out, and will
turn in a -01 with (hopefully) all your critisism taken away!

The general approach I'm taking is to start from what we can rely
on with certainty (UDP can go out and becomes bidirectional for
some time) and then try to find more optimal ways of doing the
same (can I route it locally? to my own router's external IP
through hairpin NAT? to the other router's external IPv4/port?)
and only if it works, to change the routing policy.

Interestingly, this saves 6bed4 from classifiying or understanding
NAT while it is still possible to get the best out of it.  I love
simplicity :-D

Thank you all!
 -Rick