From owner-freebsd-net@FreeBSD.ORG Wed Mar 13 15:59:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CFE956C3 for ; Wed, 13 Mar 2013 15:59:45 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail4.ijs.si [193.2.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE5618E for ; Wed, 13 Mar 2013 15:59:42 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3ZQyR25xrlzGMnK for ; Wed, 13 Mar 2013 16:59:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1363190345; x=1365782346; bh=fFM AHv1rpH1PTpeEpdzhxbrBYVGRQXyoT7QGox6mlts=; b=JgXqOXzyHUqvniY41no xaZG8b+T7j065C4vYyUmpkVKamOaw+4R9E46E2zf46ohMO290Wq2iTtnBfotHpxV vb/j/o1H20UI2LeftEt5VHIktRI6cXbSFQrrWm2vXnr+itOF4kRCHVh/azNYg0xf qoCdiMgPGopoDemS2DIWl/Lc= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id U7abi5VfjDQf for ; Wed, 13 Mar 2013 16:59:05 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Wed, 13 Mar 2013 16:59:04 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 733D26F3 for ; Wed, 13 Mar 2013 16:59:04 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-net@freebsd.org Subject: Re: ipv6 default router Operation not permitted Date: Wed, 13 Mar 2013 16:59:04 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) References: <20130312225018.GA13589@defiant.konundrum.org> <20130313135253.GA18992@defiant.konundrum.org> In-Reply-To: <20130313135253.GA18992@defiant.konundrum.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201303131659.04074.Mark.Martinec+freebsd@ijs.si> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 15:59:45 -0000 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