Re: IPv6 routing(?)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 17 Nov 2016 22:28:32 +0100
    From:        Jan Danielsson <jan.m.danielsson%gmail.com@localhost>
    Message-ID:  <03604c00-17eb-f3de-d69e-ec070d06a4db%gmail.com@localhost>

  |    This is a proper global /48 network.

That sounds good, but what is "this" there - that is, to whom is
that /48 assigned, you or the ISP ?

  |    The re0 interface is assigned a 2001:XXXX:YYYY:0:... address (from
  | the ISP) with a prefixlen of 64

That's normal, though if this is some kind of emulated P2P link, a /64
is kind of overkill..   (but that is the ISP's choice, just accept it.)

  | (there's a static route in their router
  | which is /48, but it seems routers are typically assigned /64 chunks).

Links are typically assigned /64 chunks.  Routers have interfaces to
links, each interface has an address (of each class in use) usually.

Aside from links, the only other thing (and this is true both in v4 and v6)
that is usually assigned blocks of addresses is a dhcp server (which may
be running in a router, of course.)

  |    The router's wm0 is manually assigned a /80 subnet,

Why /80 ?

  |    What works:
  |    - From the router, I can ping6/traceroute6 any address on the public
  | Internet.  (I.e. "ping6 netbsd.org" or "traceroute6 google.com" works fine).
  |    - The router can ping6 the host1's IPv6 address.
  |    - host1 can ping6 both the lan and wan addresses of the router.

That's good.

  |    What doesn't work:
  |    - From host1, I can not ping addresses on the public Internet.  (i.e.
  | ping6 netbsd.org) does not work.  traceroute6 google.com will only get a
  | reply for the first entry (2001:XXXX:YYYY:0:4::1 (the router's lan
  | interface)) and then won't progress any further.

You might need to talk to the ISP, find out exactly what is in their
routing tables.   If the suggestion below doesn't help, you should also
probably show us what is in the router's IPv6 routing table:
	netstat -rn -f inet6

Unless you have a really good reason, don't obfuscate the addresses with
XXXX YYYY that just makes it harder to see what is really happening.

  |    Typical cause for issues similar to this is that forwarding is not
  | enabled -- but it is (double and triple-checked).

v6 forwarding as well as v4 ?   (That is, what does
	 sysctl net.inet6.ip6.forwarding
return ?   (On the router))   But I assume this is OK, as you say you
see ping requests from host1 passing out re0 on the router towards
the ISP.  That working tells you that the router is forwarding packets.

  |  Plus, and correct me
  | if I'm wrong here, I can ping the router's wan address from host1 which
  | wouldn't work if IPv6 forwarding had been disabled.

No, proves nothing, we don't have enough of a strict host model for that
to be a good test.

  |    To my untrained eye, the routing tables on both host1 and the router
  | look fine; host1's default entry is to the router's link-local address
  | of the lan interface (analogous to the router's default route pointing
  | to fe80::1, autoconfigured and in accordance with the instructions from
  | the ISP).

Yes, those I expected to be fine from what you said worked.

  |    The 2001:XXXX:YYYY:0:4::/80 subnet on the router routes to link#2 (wm0).

  |    If I run "tcpdump -nttt -i re0" on the router and then try to ping6
  | netbsd.org, I can see the echo requests (from the host1 address to
  | netbsd.org's IPv6 address), but no replies.

For various reasons, ping is not always a great test (it is when it works,
but when it fails the number of possible reasons is staggering...)

But ...
  | (Running the same ping6
  | command on the router will cause both requests and replies to be seen in
  | tcpdump).

Makes it look like the ISP isn't filtering ICMPv6 (which some do, stupidly).

  |    Any tips on what I should be looking closer at?

Right now, my guess would be routing at the ISP.   I would tend to assume
that they are routing 2001:XXXX:YYYY:0::/64 to the wan link between you
and them.   That includes your carved out /80 from that /64.   If that wan
link was really an emulated ethernet (or similar) you might see the ISP's
router issuing NDP requests for your host1 on that wan link - but the lack
of those (if they are absent) proves nothing.

You might want to try using a /64 on the lan link, perhaps
	2001:XXXX:YYYY:1::/64

With that you could use autoconfig on the hosts (that requires /64 prefixes,
not bigger, not smaller) rather than manual config (or DHCP).  (You can still
do manual config of course, and might want to while you're debugging -
manually config'd addresses tend to be much easier to type!)

Of course, this is assuming that the ISP has assigned 2001:XXXX:YYYY::/48
to you.    That's the (at least original) model for how IPv6 addresses should
be assigned, but not everyone believes in the calculations of address
availability, and some want to give smaller (that is, bigger 'n' in /n)
allocations to end user organisations.

Your mention of the ISP routing the /48 via a static route in their router
makes me suspect that they are allocating you a /48 (which is good).

I know, people from the v4 world get staggered when they see the amount
of v6 address space that gets handed around, but that's just an effect of
the difference between 128 bits and 32...   When you get used to it, everything
becomes SO MUCH simpler - all of the crude hacks needed to make v4 work
simply go in the trash.

kre