Subject: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP-encapsulation

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Aug 2010 07:36:59 +0200

Hello,

I would like to ask if the addresses in draft-ietf-behave-address-format 
should also be used for stateless IPIP-encapsulation.

We (www.freifunk.net, www.olsr.org) are using large clouds of MANET routers 
for free community networks in several cities. Each router might connect to a 
local attached ethernet, some are connected to an internet uplink.

At the moment all our mesh clouds use IPv4 private addresses (most use 
10.0.0.0/8) for their interfaces and node identifiers, but we would like to 
change this to IPv6. To do this someone from Berlin wrote a linux kernel 
module to allow stateless generation of IPv4-in-IPv6 tunnel packets. We point 
an IPv4 route into a translation device and it generates an IPv6 header around 
the old packet by adding a prefix to the IPv4 source and destination address. 
The IPv6 packet will then be send to the target router.
At the moment we use the ::ffff:0:0/96 prefix for this, but this does not work 
well with all operation systems.

All IPv6 tunnel packets are only flowing inside our mesh network, the internet 
or the attached local ethernets never see this packets.

What would be a good prefix for this scenario that we can use on all mesh 
routers worldwide, so we can preconfigure it in our firmware.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Simon Perreault <[email-masked]>
Date: Tue, 03 Aug 2010 08:52:48 -0400

> routers worldwide, so we can preconfigure it in our firmware.

First, let me say I'm not convinced that this is the right deployment
model. But let's not discuss that and suppose it is.

I think each deployment should be using a different prefix. This is
probably not what you expect, as it is very different from the IPv4 way
of doing things. But I think it will make things easier down the road.

I see two possibilities:

a. Use a global-scope prefix. For example, just carve a /96 out of any
address range you have been assigned by an ISP, and use that.

b. Use a unique-local prefix. You can generate a globally-unique
local-scope prefix following
<http://tools.ietf.org/html/rfc4193#section-3.2.2>. I have a small Perl
implementation that I could perhaps share with you if you need it. Maybe
this could be run automatically by your firmware to generate a prefix on
the fly.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Aug 2010 15:09:02 +0200

On Tue August 3 2010 14:52:48 Simon Perreault wrote:
> > 10.0.0.0/8) for their interfaces and node identifiers, but we would like
> > to change this to IPv6. To do this someone from Berlin wrote a linux
> > kernel module to allow stateless generation of IPv4-in-IPv6 tunnel
> > packets. We point an IPv4 route into a translation device and it
> > generates an IPv6 header around the old packet by adding a prefix to the
> > IPv4 source and destination address. The IPv6 packet will then be send
> > to the target router.
> > At the moment we use the ::ffff:0:0/96 prefix for this, but this does not
> > work well with all operation systems.
> > 
> > All IPv6 tunnel packets are only flowing inside our mesh network, the
> > internet or the attached local ethernets never see this packets.
> > 
We are still experimenting with it, so I am open for a good advice.

> I think each deployment should be using a different prefix. 

> This is
The problem we see with this is that it's another mayor chance for 
misconfiguration for the users (each mesh router is installed and configured 
by it's own user). Especially because it has to be configured in the kernel 
module and the routing agent (our routing agent automatically set up routes 
into the encapsulation device and between the routers for the 4over6 routes). 

> address range you have been assigned by an ISP, and use that.
Most of our networks don't have public IPv6 addresses.
 
> this could be run automatically by your firmware to generate a prefix on
Would be interesting to look at this perl program.

So you think it would be better to use a custom prefix instead of a well known 
one similar to the ones suggested in http://tools.ietf.org/html/draft-ietf-
behave-address-format ?

Henning Rogge

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Aug 2010 12:34:57 -0700

Hi, Henning.

You might also ask on SOFTWIRE, where they do mesh networking and 4-over-6
and 6-over-4 tunnels.

Originally, draft-ietf-behave-address-format was intended to cover both
translation (BEHAVE) and tunneling (SOFTWIRE), but that scope didn't work
out as originally hoped.  However, the ideas in it may still work for your
purposes -- which is effectively what Simon suggested in his post when he
suggested on solution was to 'use the ISP's prefix and pick a /96' --> which
is the same as the Network-Specific Prefix (NSP) described in
draft-ietf-behave-address-format.

ULA may work well, too, even though over breakfast last week I had some
reservations about ULA if/when the MANET network is joined with another
network; but the ULAs for the tunnels don't actually need to be known to
that other network.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henning Rogge
> Sent: Tuesday, August 03, 2010 6:09 AM
> To: Simon Perreault
> Cc: [email-masked]
> Subject: Re: [BEHAVE] IPv4/IPv6 addresses for stateless IPIP-
> encapsulation
> 
> > > 10.0.0.0/8) for their interfaces and node identifiers, but we would
> > > like to change this to IPv6. To do this someone from Berlin wrote a
> > > linux kernel module to allow stateless generation of IPv4-in-IPv6
> > > tunnel packets. We point an IPv4 route into a translation device
> and
> > > it generates an IPv6 header around the old packet by adding a
> prefix
> > > to the
> > > IPv4 source and destination address. The IPv6 packet will then be
> > > send to the target router.
> > > At the moment we use the ::ffff:0:0/96 prefix for this, but this
> > > does not work well with all operation systems.
> > >
> > > All IPv6 tunnel packets are only flowing inside our mesh network,
> > > the internet or the attached local ethernets never see this
> packets.
> > >
> > > What would be a good prefix for this scenario that we can use on
> all
> > > mesh routers worldwide, so we can preconfigure it in our firmware.
> >
> > probably not what you expect, as it is very different from the IPv4
> > way of doing things. But I think it will make things easier down the
> road.
> misconfiguration for the users (each mesh router is installed and
> configured by it's own user). Especially because it has to be
> configured in the kernel module and the routing agent (our routing
> agent automatically set up routes into the encapsulation device and
> between the routers for the 4over6 routes).
> 
> > I see two possibilities:
> >
> > <http://tools.ietf.org/html/rfc4193#section-3.2.2>. I have a small
> > Perl implementation that I could perhaps share with you if you need
> > it. Maybe this could be run automatically by your firmware to
> generate
> > a prefix on the fly.
> So you think it would be better to use a custom prefix instead of a
> well known one similar to the ones suggested in
> http://tools.ietf.org/html/draft-ietf-
> behave-address-format ?
> 
> Henning Rogge
> --
> Kommunikationssysteme (KOM) Neuenahrer Straße 20, 53343 Wachtberg,
> Germany

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Aug 2010 21:41:27 +0200

> You might also ask on SOFTWIRE, where they do mesh networking and 4-over-6
Thank you for the advice, I will ask there too.
 
> suggested on solution was to 'use the ISP's prefix and pick a /96' -->
> which is the same as the Network-Specific Prefix (NSP) described in
Okay.

Is there an implementation of the IPv4/IPv6 stateless translation as a linux 
kernel module ? 

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Aug 2010 13:06:28 -0700

> Sent: Tuesday, August 03, 2010 12:41 PM
> To: [email-masked]
> Cc: 'Henning Rogge'; Dan Wing
> > You might also ask on SOFTWIRE, where they do mesh networking and
> > 4-over-6 and 6-over-4 tunnels.
> > Originally, draft-ietf-behave-address-format was intended to cover
> > both translation (BEHAVE) and tunneling (SOFTWIRE), but that scope
> > didn't work out as originally hoped.  However, the ideas in it may
> > still work for your purposes -- which is effectively what Simon
> > suggested in his post when he suggested on solution was to 'use the
> > ISP's prefix and pick a /96' --> which is the same as the
> > Network-Specific Prefix (NSP) described in draft-ietf-behave-address-
> format.
> Okay.
> 
> Is there an implementation of the IPv4/IPv6 stateless translation as a
> linux kernel module ?

I am aware of http://linux.ivi2.org/impl/

-d