v6 vs gif

[der Mouse]

The machine at work that was routing v6 developed a bad spot on its
disk. As a matter of convenience (what I had on a disk at ready hand),
I tried to set up 4.0 to do the same job.

But it doesn't work. It involves a gif v6-in-v4 tunnel. I had to add
a "create" (the former OS was pre-cloners), but then the next thing I
ran into was:

# ifconfig gif0 create
-> works fine

# ifconfig gif0 tunnel (our v4 address) (our peer's v4 address)
-> works fine

# ifconfig gif0 inet6 (our v6 address) (our peer's v6 address)
ifconfig: SIOCAIFADDR: Invalid argument

I had a look at gif(4) and didn't see any reason to think this
shouldn't work. Explicitly including "ifconfig gif0 up" before the
attempt to set the v6 addresses doesn't help; the only apparent
difference it makes is that gif0 acquires a link-local v6 address.
"route -n flush -inet6" doesn't help either.

My first suspicion was that the kernel didn't have v6 support, but
every up interface has a link-local v6 address, which kills that theory.

Is this pilot error of some sort, something I should be doing
differently under 4.0? Or is gif busted? Or what? (I can give full
details, but would rather not include real addresses on an archived
list.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

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

[Michael van Elst]

Post by der Mouse
# ifconfig gif0 inet6 (our v6 address) (our peer's v6 address)
ifconfig: SIOCAIFADDR: Invalid argument

Please add a 'prefixlen 128', the default is '64' and is invalid
for host addresses.

[der Mouse]

Post by der Mouse
# ifconfig gif0 inet6 (our v6 address) (our peer's v6 address)
ifconfig: SIOCAIFADDR: Invalid argument

Please add a 'prefixlen 128', the default is '64' and is invalid for
host addresses.

Oho! That would explain it. (Surely the default should be 128 when
setting local-&-remote addresses on a point-to-point link? Is there
something (else) I'm missing here, or should I send- this -PR?)

That seems to work. At least, the command completes without
complaining, and "ifconfig gif0" shows the addresses there.

Still doesn't _work_, but that's a separate issue. (tcpdump seens
packets being sent on gif0, but they never emerge from the underlyign
interface. I'm seeing some indications that the real problem is with
the underlying v4 routing; if I get stuck resolving it I may come back
here with that aspect too.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

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

[Greg Troxel]

Post by der Mouse

Post by der Mouse
# ifconfig gif0 inet6 (our v6 address) (our peer's v6 address)
ifconfig: SIOCAIFADDR: Invalid argument

Please add a 'prefixlen 128', the default is '64' and is invalid for
host addresses.

Oho! That would explain it. (Surely the default should be 128 when
setting local-&-remote addresses on a point-to-point link? Is there
something (else) I'm missing here, or should I send- this -PR?)
That seems to work. At least, the command completes without
complaining, and "ifconfig gif0" shows the addresses there.

I had the same issue, but the sixxs.net wiki had good examples.

I agree this is non-intuitive, and should certainly be documented, maybe
in gif(4). I had the impression v6 was always /64, but p2p links seem
to have two /128s even if a whole /64 is assigned to the link. If
standards really do say that /128 is right, gif should deal with just
addresses.

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

[der Mouse]

Post by Greg Troxel

Post by Michael van Elst

Post by der Mouse
# ifconfig gif0 inet6 (our v6 address) (our peer's v6 address)
ifconfig: SIOCAIFADDR: Invalid argument

Please add a 'prefixlen 128',

I agree this is non-intuitive, and should certainly be documented,
maybe in gif(4). I had the impression v6 was always /64, but p2p
links seem to have two /128s even if a whole /64 is assigned to the
link. If standards really do say that /128 is right, gif should deal
with just addresses.

Seems to me someone certainly should, whether it's gif or ifconfig. I
can't see any reason to even _have_ a netmask on a point-to-point link,
but even if there is one, ISTM ifconfig should at least default to
something that doesn't error out.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

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

[Daniel Hagerty]

Post by Greg Troxel
I agree this is non-intuitive, and should certainly be documented, maybe
in gif(4). I had the impression v6 was always /64, but p2p links seem
to have two /128s even if a whole /64 is assigned to the link. If
standards really do say that /128 is right, gif should deal with just
addresses.

Non /64 prefix lengths is contrary to du jure standard for
prefixes in 2000::/3. (rfc4291 section 2.5.4)

De facto reality is a completely different matter. There is a
notable amount of operational resistence to /64 on p2p links. RFC3627
documents a "considered harmful" configuration and points at a couple
of alternatives, including /128.

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

[der Mouse]

Non /64 prefix lengths is contrary to du jure standard for prefixes
in 2000::/3. (rfc4291 section 2.5.4)

Oh, ouch. That's just insane. That certainly will be one RFC I'll be
ignoring (well, that I'll continue to ignore). Didn't the v6 people
learn _anything_ from the breakdown of v4 address classes?!

De facto reality is a completely different matter. There is a
notable amount of operational resistence to /64 on p2p links.

What would it even _mean_?

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
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, 30 Jan 2009 11:18:07 -0500 (EST)
From: der Mouse <***@Rodents-Montreal.ORG>
Message-ID: <***@Sparkle.Rodents-Montreal.ORG>

| > Non /64 prefix lengths is contrary to du jure standard for prefixes
| > in 2000::/3. (rfc4291 section 2.5.4)
|
| Oh, ouch. That's just insane.

Yes it is. Fortunately it is also a meaningless requirement, totally
unenforceable (or even detectable from outside).

There's some stuff that only works on /64 prefixes, and that's fine, as
long as you don't mind that stuff not working (which is almost certainly
going to be true on a gif link) then use whatever prefix length you like.

The only thing we need to watch for are that systems (like NetBSD) don't
start to try to enforce this gibberish - fortunately NetBSD has never
even considered it that I'm aware of.

| Didn't the v6 people
| learn _anything_ from the breakdown of v4 address classes?!

The people who designed v6 didn't include any of this trash, This
has been added by people who want to be able to control other people's use
of address space for all kinds of stupid reasons.

| > De facto reality is a completely different matter. There is a
| > notable amount of operational resistence to /64 on p2p links.
|
| What would it even _mean_?

Part of the idea is that there are supposed to be a whole set of reserved
anycast addresses on every prefix, the idea is that given any address
you (anyone) can calculate the anycast address of the X on the link, if
there is one. There's no requirement that there be an X on the link of
course, but they want everyone to reserve all these addresses anyway...

kre


--
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 der Mouse
Seems to me someone certainly should, whether it's gif or ifconfig. I
can't see any reason to even _have_ a netmask on a point-to-point link,

There are some gif tunnels that are run as a full LAN, complete with
neighbour discovery.

-is

[der Mouse]

Post by Ignatios Souvatzis

Post by der Mouse
Seems to me someone certainly should, whether it's gif or ifconfig.
I can't see any reason to even _have_ a netmask on a point-to-point
link,

There are some gif tunnels that are run as a full LAN, complete with
neighbour discovery.

But then it's no longer point-to-point, is it? That sounds more like a
broadcast network (with a hard limit of two hosts, but still).

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

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

[S.P.Zeidler]

Hi,

Post by der Mouse

Non /64 prefix lengths is contrary to du jure standard for prefixes
in 2000::/3. (rfc4291 section 2.5.4)

Oh, ouch. That's just insane. That certainly will be one RFC I'll be
ignoring (well, that I'll continue to ignore). Didn't the v6 people
learn _anything_ from the breakdown of v4 address classes?!

Maybe they actually did the math?

There are 65536 /64 in a /48, which is supposed to be a 'site' network
handed out to everybody who asks for addresses for more than one LAN.

Using something smaller than a /64 on an ethernet is going to achieve
what, exactly? Are you in great danger of exhausting the >65000 networks?

Even if you took the smaller assignment talked about for residentials,
a /56, you still get 256 /64 and I dare you show me a network that
isn't a provider that would exhaust that in a single site.

So, enforce a /64 netmask, bad. Not use one on broadcast media, stupid.

regards,
spz

PS: if there's going to be an IPv6 shortage it'll not be because of /64 or
longer, it's going to be because of /32 (LIR allocation) or longer.

[Ignatios Souvatzis]

Post by der Mouse

Non /64 prefix lengths is contrary to du jure standard for prefixes
in 2000::/3. (rfc4291 section 2.5.4)

Oh, ouch. That's just insane. That certainly will be one RFC I'll be
ignoring (well, that I'll continue to ignore). Didn't the v6 people
learn _anything_ from the breakdown of v4 address classes?!

De facto reality is a completely different matter. There is a
notable amount of operational resistence to /64 on p2p links.

What would it even _mean_?

Hm?

There are a lot of things out there that build on the flexibility of
a de-facto guaranteed /64 - e.g. cryptographically generated addresses
and the privacy stuff. Treating your connection as a LAN basically means
that all that stuff works, too, even on a p2p link.

Of course, for a transport link far away from source and destination
of packets, this doesn't matter. But those don't even need more than
link-local addresses *for the link*, if they insist to save on /64's.

Regards,
-is