ipv6 default router Operation not permitted

[Mark Martinec]

On Wednesday March 13 2013 Schrodinger wrote:
> This isn't my network so I don't have any input into the matter. This
> is the OVH configuration for their dedicated servers, at least in my
> product range.
> 
> > [1] http://help.ovh.com/Ipv4Ipv6#link10
> I read this, I made sure to read this and then I read it a second time.
> No where does it indicate the use of a /56. I am in the process of a
> migration from an old OVH server to a new OVH server. My old box uses
> the /56 prefix length "fix" but based on the documentation this is
> incorrect and IMO this assumes that anyone else in the /56 is in the
> same segment as me and if they are using /64 - well, There Be Dragons.

> I am informed that I must configure my interface to /64 by OVH. The same
> as everyone else. So if everyone was on a /64 then we will send packets
> to each other via our shared default gateway.

> If I were to change my interface prefix length to /56 my host would no
> longer consider the need to send packets to the default gateway for any
> host within this /56. I would simply perform Neighbour Solicitation on
> my link.

> I am informed that I must configure my interface to /64 by OVH. The same
> as everyone else. So if everyone was on a /64 then we will send packets
> to each other via our shared default gateway.

Fleuriot Damien writes:
> OVH allocates a /64 per customer.
> To avoid having to setup 1 gateway per customer, they set up a single one
> within a /56, allowing for 256 /64s

I see, nasty.

> This mimics the situation where your host gives you a /32 ipv4 within
> a /24 network and uses a single gateway, again for 250ish customers.

No it doesn't. That would be true if a mask on the interface were /32,
in which case there would again be a problem reaching a default router
in absence of an ARP entry.

Similarly if a net would be a /16 and an interface would be given
a /24 mask and a router would be outside of this /24 subnet,
even if on the same L2 link.

> Does adding the interface route not put the default gateway on-link
> though ?

I don't think it does. The on-link state of an address comes
from matching the address to a set of prefixes on an interface,
or finding it in the ndp cache - perhaps as a result of receiving
a redirect messages, or manually.


RFC 4861 section 2.1.:

on-link - an address that is assigned to an interface on a
          specified link.  A node considers an address to be
          on-link if:

  - it is covered by one of the link's prefixes (e.g.,
    as indicated by the on-link flag in the Prefix
    Information option), or

  - a neighboring router specifies the address as the
    target of a Redirect message, or

  - a Neighbor Advertisement message is received for
    the (target) address, or

  - any Neighbor Discovery message is received from
    the address.


> Also from the information I have received, router advertisements may be
> turned off in the future, my host should simply Neighbour Solicit for
> the global scope unicast address of my default gateway.

A host would not send a Neighbour Solicitation for an address
which is not considered on-link:

RFC 4861 section 7.2

  Address resolution is the process through which a node determines the
  link-layer address of a neighbor given only its IP address.  Address
  resolution is performed only on addresses that are determined to be
  on-link and for which the sender does not know the corresponding
  link-layer address (see Section 5.2).


> was that because of the host route for the default gateway FreeBSD does
> not solicit for the "on-link gateway" because the interface is not set 
> to ACCEPT_RTADV. But that doesn't make immediate sense.
> 
> And as pointed out in previous emails without ACCEPT_RTADV for
> re0 - FreeBSD does not perform this action.

The router's link-layer address is available in RA messages.
If you turn off ACCEPT_RTADV (or if a router does not send them),
the only way to obtain a router's link-layer address would be
by sending a Neighbour Solicitation (which is only sent to an
address which is considered on-link), or by manually placing
it in the NDP cache.

> So again, what is the correct way ? I think this is a debate of IPv6
> Protocol vs. IPv6 Policy vs. Network architecture.

I'm not sure, but it appears to me that adding the router's
link-layer address to the NDP cache looks like the only
reliable way, in absence or router advertisements.

  Mark