Date: Sat, 12 May 2001 10:33:18 +0900 From: itojun@iijlab.net To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Nick Rogness <nick@rogness.net>, freebsd-net@FreeBSD.ORG Subject: Re: gif tunnel woes Message-ID: <12623.989631198@itojun.org> In-Reply-To: louie's message of Fri, 11 May 2001 18:02:20 -0400. <200105112202.f4BM2K256031@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> my preference is to dropp support for multi-destination mode from >> gif(4), as the multi-destination behavior is violating network layering >> (rt_gateway is in inner header, and gif(4) multi-destination mode >> uses it to determinte outer header). > >There's certainly a bunch of NBMA network media out there. The problem is >abusing the routing table next hop as a way to specify the remote >tunnel endpoint. This should be an attribute of the gif interface, >configured outside of the routing infrastructure. Or, perhaps treated >like ARP for ethernet; it's just an accident that the "MAC" address for >a multi-point NBMA tunnel is an IPv4/IPv6 address. well, in the case of ARP entries, you know that it is a layer-2 address (MACaddress) on rt_gateway because it is tagged as AF_LINK. for the routing entries used by gif multi desination mode, rt_gateway field is not distinguishable (if it is outer addr or inner addr). also i guess it unsuitable to compare with NBMA networks, as with most of the NBMA networks i guess rt_gateway field takes an AF_LINK sockaddr, not an AF_INET. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12623.989631198>