I'm trying to make a 6rd pseudo-device

[Patrick Klos]

Hello tech-net:

I am trying to make my own 6rd pseudo-device for NetBSD (partly, to try
to use Comcast's 6rd support, and partly to learn more about how these
kinds of drivers work?). I'm building with current (5.99.43).

I modeled my 'sixrd' driver after the 'stf' driver since they're both
doing almost the same tunneling with just a few different rules.

After creating the device, I configure it with the IPv6 address
2001:55c:62d8:93c7::1:

ifconfig sixrd0 inet6 2001:55c:62d8:93c7::1 prefixlen 32

Then I try to ping6 to 2001:55c:62d8:93c7::2 which should force the
packets to/thru my driver, but instead, I get the following:

lily# ping6 2001:55c:45fc:5042::2
PING6(56=40+8+8 bytes) 2001:55c:62d8:93c7::1 --> 2001:55c:45fc:5042::2
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
^C
--- 2001:55c:45fc:5042::2 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

I have a debug statement in the sixrd_output() routine, so I'd see if
any packets were trying to be sent.

It's almost as if the IPv6 stack is checking the length, and thinking
the packet is too big to send on the target interface?

My device's settings are all identical to what the stf driver uses. Any
ideas?

Thanks,

Patrick Klos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by Patrick Klos
I am trying to make my own 6rd pseudo-device for NetBSD (partly, to
try to use Comcast's 6rd support, and partly to learn more about how
these kinds of drivers work?). I'm building with current (5.99.43).
I modeled my 'sixrd' driver after the 'stf' driver since they're
both doing almost the same tunneling with just a few different
rules.
After creating the device, I configure it with the IPv6 address
ifconfig sixrd0 inet6 2001:55c:62d8:93c7::1 prefixlen 32
Then I try to ping6 to 2001:55c:62d8:93c7::2 which should force the
lily# ping6 2001:55c:45fc:5042::2
PING6(56=40+8+8 bytes) 2001:55c:62d8:93c7::1 --> 2001:55c:45fc:5042::2
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
^C
--- 2001:55c:45fc:5042::2 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
I have a debug statement in the sixrd_output() routine, so I'd see
if any packets were trying to be sent.
It's almost as if the IPv6 stack is checking the length, and
thinking the packet is too big to send on the target interface?
My device's settings are all identical to what the stf driver uses.
Any ideas?

what MTU did you set? ifconfig sixrd0

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Fri, 21 Jan 2011 15:05:05 -0500
From: Patrick Klos <***@klos.com>
Message-ID: <***@klos.com>

| ifconfig sixrd0 inet6 2001:55c:62d8:93c7::1 prefixlen 32

Why /32? That looks wrong, looks to be /64 to me - this looks to be
copied a bit too slavishly from stf (but even there I'd expect a /48
if not /64).

| It's almost as if the IPv6 stack is checking the length, and thinking
| the packet is too big to send on the target interface?

Unlikely, ping6 sends (by default) really small packets, way smaller
than the smallest legal MTU for IPv6. More likely the error message
is one of those that is being abused for some similar purpose, and just
means "too much something" - perhaps internal routing table loop, or
who knows ... What does the kernel routing table look like
(netstat -rn -f inet6)
when the interface is configured?

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Patrick Klos]

Post by Robert Elz
Date: Fri, 21 Jan 2011 15:05:05 -0500
| ifconfig sixrd0 inet6 2001:55c:62d8:93c7::1 prefixlen 32
Why /32? That looks wrong, looks to be /64 to me - this looks to be
copied a bit too slavishly from stf (but even there I'd expect a /48
if not /64).

I modeled my setup after the 6to4 (stf) driver's setup. I haven't
analyzed the routing implications yet - I'm just going with what stf
does right now. (what you said makes more sense to me also, but I wanted
to get it working first)

Post by Robert Elz
| It's almost as if the IPv6 stack is checking the length, and thinking
| the packet is too big to send on the target interface?
Unlikely, ping6 sends (by default) really small packets, way smaller
than the smallest legal MTU for IPv6. More likely the error message
is one of those that is being abused for some similar purpose, and just
means "too much something" - perhaps internal routing table loop, or
who knows ...

Actually, it turns out I broke my MTU setting myself, so it was zero.
This was my initial problem. I have since gotten my driver to work with
Comcast's 6rd bridge router.

Post by Robert Elz
What does the kernel routing table look like
(netstat -rn -f inet6)
when the interface is configured?

Once I fixed my MTU issue, it only took a little debugging to get the
rest to work. I'm considering merging my code into the stf driver
rather then to have a separate sixrd driver?

Thanks for your comments.

Patrick


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

the rest to work. I'm considering merging my code into the stf
driver rather then to have a separate sixrd driver?

As far as I read 6RD, it's just like 6to4, just with a different
(and normally longer) prefix than 2002::/16 ?

6to4 should certainly be implementable as a special case of a 6rd
driver, or stf should be easily extandable. Note however, that for
6to4 the intrinsic prefix length is always (16+32)==48, while for
6rd it can be anything from (in theory) 3+32 to 32+32. So there's
a small integer parameter more - the position of the embedded
IPv4 relay address.

(The advertized prefix length for both cases might be smaller,
although not smaller than 64).

If you do merging, be careful to add/keep the basic security
settings. (see $(man stf))

-is


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Mon, 24 Jan 2011 15:05:19 +0100
From: Ignatios Souvatzis <***@NetBSD.org>
Message-ID: <***@beverly.kleinbus.org>

| As far as I read 6RD, it's just like 6to4, just with a different
| (and normally longer) prefix than 2002::/16 ?

And a magic IPv4 address that needs to be configured per site,
rather than simply copied from the RFC into the code.

| 6to4 should certainly be implementable as a special case of a 6rd
| driver,

Yes, that's the way to approach it.

| or stf should be easily extandable.

And that's probably the way to achieve it. Aside from
anything else, stf is a "nicer" interface name than "sixrd",
and (unfortunately) "6rd" won't work I don't think.

| So there's a small integer parameter more - the position of
| the embedded IPv4 relay address.

The number of bits of that address might also need to be
configured (where the less significant bits are the ones that
are used - the upper bits would be configured elsewhere).

There's also the v4 address of the border router, which is
not a constant in 6rd as it is in 6to4.

And while a 6to4 would (or should, or perhaps just could)
reject attempts to use 1924 addresses as the basis for the
v6 prefix, 6rd can't do that.

kre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Ignatios Souvatzis
6to4 should certainly be implementable as a special case of a 6rd
driver, or stf should be easily extandable.

FWIW, that's what they did in
<http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2010-09/msg00165.html>.

Dave

[Jed Davis]

Post by Ignatios Souvatzis

the rest to work. I'm considering merging my code into the stf
driver rather then to have a separate sixrd driver?

As far as I read 6RD, it's just like 6to4, just with a different
(and normally longer) prefix than 2002::/16 ?
6to4 should certainly be implementable as a special case of a 6rd
driver, or stf should be easily extandable. Note however, that for
6to4 the intrinsic prefix length is always (16+32)==48, while for
6rd it can be anything from (in theory) 3+32 to 32+32. So there's
a small integer parameter more - the position of the embedded
IPv4 relay address.

More than that -- 6RD allows for removing some bits from the beginning
of the IPv4 address. So if a provider is delivering v6 service to
172.19.0.0/16, they could set IPv4MaskLen as high as 16 and use a prefix
like 2001:db8:beef::/48. Or a shorter prefix than that. So there are
two small integer parameters here, as well as those bits of the v4
address that are masked off.

(In fact, from my first read through it, RFC 5969 doesn't explicitly
forbid giving each v4 address a prefix smaller than a /64; that will
break stateless autoconfiguration of the end network, of course, but it
is possible. The only restriction like that that I'm seeing is that the
resulting prefix must be at least a /128 -- for obvious reasons.)

It does look like 6to4 can be considered the special case of 6RD with
IPv4MaskLen=0, 6rdPrefix=2002::, and 6rdPrefixLen=16.
--
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k))))))) '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Geert Hendrickx]

Post by Patrick Klos
I am trying to make my own 6rd pseudo-device for NetBSD (partly, to
try to use Comcast's 6rd support, and partly to learn more about how
these kinds of drivers work?). I'm building with current (5.99.43).
I modeled my 'sixrd' driver after the 'stf' driver since they're
both doing almost the same tunneling with just a few different
rules.
After creating the device, I configure it with the IPv6 address
ifconfig sixrd0 inet6 2001:55c:62d8:93c7::1 prefixlen 32
Then I try to ping6 to 2001:55c:62d8:93c7::2 which should force the
lily# ping6 2001:55c:45fc:5042::2
PING6(56=40+8+8 bytes) 2001:55c:62d8:93c7::1 --> 2001:55c:45fc:5042::2
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
ping6: sendmsg: Message too long
ping6: wrote 2001:55c:45fc:5042::2 16 chars, ret=-1
^C
--- 2001:55c:45fc:5042::2 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
I have a debug statement in the sixrd_output() routine, so I'd see
if any packets were trying to be sent.
It's almost as if the IPv6 stack is checking the length, and
thinking the packet is too big to send on the target interface?
My device's settings are all identical to what the stf driver uses.
Any ideas?
Thanks,
Patrick Klos

Hi Patrick,

did you get this working eventually? Do you have code to share?


Geert