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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
