public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Etaoin Shrdlu <shrdlu@unlimitedmail.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] IPv6 troubles
Date: Thu, 19 Jul 2007 18:09:47 +0200	[thread overview]
Message-ID: <200707191809.47936.shrdlu@unlimitedmail.org> (raw)
In-Reply-To: <200707191602.45433.mike@gaima.co.uk>

On Thursday 19 July 2007 17:02, Mike Williams wrote:

> I hadn't configured the "subnet router anycast address", but I can
> still ping it. Again makes no difference if it's specified or not.

Ok, then probably the linux implementation recognizes it anyway. But it 
seems this is not the issue here.

> interface bond2
> {
>         AdvSendAdvert on;
>         prefix dead:beef:2:136::/64
>         {
>                 AdvOnLink on;
>                 AdvAutonomous on;
>         };
> };

Looks OK.

> As above, no difference. I've even tried using the link-local address
> of the upstream router for the default route out of the firewall.

> # ip -6 route show
> dead:beef:2::/64 dev bond0  metric 1  expires 21253232sec mtu 1500
> advmss 1440 hoplimit 4294967295 

> dead:beef:2::/64 dev bond0  metric 256 expires 21254724sec mtu 1500
> advmss 1440 hoplimit 4294967295 

> dead:beef:2:131::/64 dev bond1  metric 256  expires 21256488sec mtu
> 1500 advmss 1440 hoplimit 4294967295 

> dead:beef:2:136::/64 dev bond2  metric 256  expires 21252676sec mtu
> 1500 advmss 1440 hoplimit 4294967295 

> dead:beef:2:137::/64 dev bond4  metric 256  expires 21255086sec mtu
> 1500 advmss 1440 hoplimit 4294967295 

> default via fe80::214:f600:b67e:b4db dev bond0 metric 1  expires
> 21334235sec mtu 1500 advmss 1440 hoplimit 4294967295

Ok, so fe80::214:f600:b67e:b4db *is* your provider's router interface.

You should also have, for each interface, a route to fe80::/64 and one to 
ff00::/8, eg something like

fe80::/64 dev bond1 ...
ff00::/8 dev bond1 ...

for each interface.

And at each internal host you should have a route to 
dead:beef:2:xxx::/64, one to fe80::/64, one to ff00::/8, and a default 
route pointing to the link-local address of the router interface on that 
link.

> firewall # ip -6 neigh
> fe80::214:f600:b67e:b4db dev bond0 lladdr 00:14:f6:7e:b4:db router
> STALE 
> dead:beef:2:136:204:23ff:fed7:e86a dev bond2 lladdr 00:04:23:d7:e8:6a
> REACHABLE 
> fe80::204:23ff:fed7:e86a dev bond2 lladdr 00:04:23:d7:e8:6a STALE
>
> host # ip -6 neigh
> dead:beef:2:136::11 dev bond0 lladdr 00:04:23:d7:f3:32 router
> REACHABLE 
> fe80::204:23ff:fed7:f332 dev bond0 lladdr 00:04:23:d7:f3:32 
> router REACHABLE

I assume you took this immediately after pinging the global firewall 
address (manually assigned, I supposed), otherwise the entry 
dead:beef:2:136::11 would have no reason to be there.

Everything seems ok so far.
The thing left to understand is why your provider's router, when it 
receives a packet coming from an internal host of yours, tries to do a 
neighbor discovery (similar to ARP) on that address.

I'd make sure that everything is configured correctly at the far side of 
the link. If you don't do dynamic routing with them (and if you are 
single-homed you probably don't), they should have a static route 
pointing to dead:beef:2::/48 via your firewall's bond0 link-local 
address. 

Their end of the link should definitely have a /64 (or longer) address, 
as should your end; the behaviour we are seeing /could/ mean that they 
have configured their end with a /48 address from the same pool, thus 
erroneously thinking that all the addresses belonging to your /48 block 
(ie, everything starting with dead:beef:2) belong to the link between 
you and them.

If neither of you needs said link to be pingable or otherwise reachable, 
you can also (like I do) avoid assigning global addresses to the link 
altogether and only use link-local addresses, thereby saving global 
addresses (not a concern with ipv6, but anyway...).
-- 
gentoo-user@gentoo.org mailing list



  reply	other threads:[~2007-07-19 16:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-19 11:45 [gentoo-user] IPv6 troubles Mike Williams
2007-07-19 12:56 ` Etaoin Shrdlu
2007-07-19 15:02   ` Mike Williams
2007-07-19 16:09     ` Etaoin Shrdlu [this message]
2007-07-19 15:12   ` Etaoin Shrdlu
2007-07-19 16:00     ` Mike Williams
2007-07-19 16:51       ` Etaoin Shrdlu
2007-07-19 18:17         ` Mike Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200707191809.47936.shrdlu@unlimitedmail.org \
    --to=shrdlu@unlimitedmail.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox