From owner-freebsd-hackers@freebsd.org Mon Apr 26 15:35:54 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E4E3D5E559C for ; Mon, 26 Apr 2021 15:35:54 +0000 (UTC) (envelope-from zlei.huang@gmail.com) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FTTWF6Pc6z3mCm for ; Mon, 26 Apr 2021 15:35:53 +0000 (UTC) (envelope-from zlei.huang@gmail.com) Received: by mail-pl1-x633.google.com with SMTP id b21so632128plz.0 for ; Mon, 26 Apr 2021 08:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=9Gxqs9fhtA/dPkbzpZkD76JEnwmaP+8EJKetcWHqNUo=; b=rWONd2XiaHFPHpEY94VMxrYgm+bb6fa/IX7IKTUOlkKd3yTR6pRwnr653bKxET74ly iXQH24ZXd2gIvnApYdhtzrpX9PYudAT+NpS1dUg/jfpFRIK9KC6VXmLeU2vVWKfY5VTh d6ioDDDW5dCzYzND3ZkIqo8up3L3y+q4NoZKLkbwcDYLoh3m6X/Xfe0AZOgnNSDWENFG JsC1ar2s16yHuLoxEOeJ+GVHDyqgkpdPrLLAJON5BZP4fumrjkjImmuoqxzaJfJIVa8/ 1ZQFMtbt5yYHHTGSt54ICeG7VK0W5i/PecnDvSzcJF93mABGgNwDESQ8VtNk6FErTLbM 6RZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=9Gxqs9fhtA/dPkbzpZkD76JEnwmaP+8EJKetcWHqNUo=; b=LCY2fmuYEpaVqE2dcdeX7oKgxcR7YnV78yLnhWyaJol3YGzk6CMnrGX+E+KZQfZseU 5QXQcqXsggodQHYOwXgH2ROVZlkCiJ6BaEoFk3yN0NJdleRwwKF3TPFSVHqT9DSZtCO7 FXQ6FRRlW8M7+N/2XWgJh/B7uk/GEuYAzdBriYpYLmgy5pkla/gBp5xKfCKGmv0GqI1K U5S9Buus7A2kQ8Kowk6oNknr1M58b3rx8MJ/OSOaWDU6GK1go1I/+PxnKhUdAXjhehP/ +bGC5OWqoydy1TXG2LFCCwD39qbMNQzR8UppDmcmD4mvaFY1geZHN0feG8zHxIiwPXwK zkzg== X-Gm-Message-State: AOAM5320MNFweSdMQVCOC8RQ0YMGofiZanqa5nBQraDwGUeYKa7kw3O5 1rj9nLl75e1gzBy3r1vuY1hboU4GO84= X-Google-Smtp-Source: ABdhPJyWfTZ5Uvx+rUyYTsiHRRq9tRyiDtpuPrPxtbX/3qwzIUmLbqPN5pmT+ogW5F6bNAM7SWdeZg== X-Received: by 2002:a17:902:b406:b029:ec:fbf2:4114 with SMTP id x6-20020a170902b406b02900ecfbf24114mr12098251plr.32.1619451352274; Mon, 26 Apr 2021 08:35:52 -0700 (PDT) Received: from [172.17.252.129] (ns1.oxydns.net. [45.32.91.63]) by smtp.gmail.com with ESMTPSA id w10sm121883pfq.184.2021.04.26.08.35.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Apr 2021 08:35:51 -0700 (PDT) From: Zhenlei Huang Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Fwd: Are there any RFCs for address selection for IPv4 Date: Mon, 26 Apr 2021 23:35:38 +0800 References: <202104261401.13QE17Jb097948@gndrsh.dnsmgr.net> Cc: freebsd-hackers@freebsd.org To: "Rodney W. Grimes" Message-Id: <937C7998-7689-4D27-88B4-96C53F0E6F97@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4FTTWF6Pc6z3mCm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=rWONd2Xi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zleihuang@gmail.com designates 2607:f8b0:4864:20::633 as permitted sender) smtp.mailfrom=zleihuang@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::633:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::633:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::633:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 15:35:55 -0000 > Begin forwarded message: >=20 > From: "Rodney W. Grimes" > Subject: Re: Are there any RFCs for address selection for IPv4 > Date: April 26, 2021 at 10:01:07 PM GMT+8 > To: Zhenlei Huang > Cc: "Rodney W. Grimes" , = freebsd-hackers@freebsd.org >=20 >> Hi Rod Grimes, >>=20 >>=20 >>> On Apr 25, 2021, at 9:40 PM, Rodney W. Grimes = wrote: >>>=20 >>>> Hello hackers, >>>>=20 >>>> For IPv6 there's RFC 6724 to clarify the default address selection = procedure,=20 >>>> both for source address selection and destination address = selection. Are there >>>> any RFCs like RFC 6724 that are for IPv4?=20 >>>=20 >>> The important difference I think here is that in IPv6 it is very = normal to >>> have both a link local and a routable IP address on an interface. = RFC 3927 >>> speaks to this for IPv4 with: >>> IPv4 Link-Local addresses are not suitable for communication with >>> devices not directly connected to the same physical (or logical) >>> link, and are only used where stable, routable addresses are not >>> available (such as on ad hoc or isolated networks). This document >>> does not recommend that IPv4 Link-Local addresses and routable >>> addresses be configured simultaneously on the same interface. >>>=20 >>> Though technically you have not put a global uniq unicast address on = the >>> outbound interface the fact your trying to route one via that = interface >>> to a loopback interface puts you into the situation your attempting >>> to route global IP over a link local address. =20 >>>>=20 >>>> I'm exploring RFC 3927, consider this situation, a host configured = with link-local >>>> address on NIC and global unicast alias address on loopback = interface, and default route to=20 >>>> the link-local address of router (some ISPs do this). The current = implementation kernel >>>> will use the link-local address as the source address when = initializing a connection to=20 >>>> remote host via the default route. It seems wrong, as link-local = address are not=20 >>>> routable as per RFC 3927. >>>=20 >>> So your wanting the kernel to pick a source address on another = interface >>> for a packet going out a different interface, that is what seems = wrong. >>=20 >> I'm not sure if this is proper for IPv4, but in the IPv6 network = stack, FreeBSD's >> current implementation select global unicast address over link-local = address, in case >> the outgoing interface does not have any global unicast addresses. >> I'm wondering whether it makes sense also for IPv4. >=20 > This is due to the fact that IPv6 is specified to have this type of > behavior. In v6 we have the idea of scope, that does not exist in > the v4 world, or at least at this time it does not. RFC3927 3.2 does > discuss the idea of scope and v4. I have got noticed the limitation of the current implementation of IPv4 = scope. Basically it confuses to have two or more interfaces all configured with = LL addresses. >=20 >>>=20 >>> Though I think this could be solved by applying a technique used in >>> routers, and that is the concept of a host specific globally = routeable >>> IP address that should be used for all non-local packets. This is = useful >>> in complex multipath networks as the router is always accessable via >>> that IP address no mater which interfaces are routing packets = correctly >>> as long as the routing protocols are maintaining a path to it. >>>=20 >>> But before going down that road, why are you putting your desired = globally >>> routeable IP address on lo0 and not on the upstream interface which = would >>> eliminate this problem? Is it because you have a complex multipath = network, >>> or is it from an attempt to save some global IP's that would be = needed >>> to run these on the link? Or? >>>=20 >>=20 >> Reading RFC 3927 2.7, it states link-local addresses are not = routable. The router shall >> discard those packets from or to link-local addresses. Then it make = no sense for a host >> to select link-local address as source address when it initialize a = connection, except for=20 >> an edge case that the destination is also link-local address. >=20 > In my reply to Poul Henning I wrote that allowing a ipv4 LL address > as a next hop may be a violation of RFC, and is the root cause of > this address selection process. For route I think it is valid to have a LL as next-hop. In the routing = world the next-hop would be 'translated' to layer 2 address, regardless the mean, ARP or NDP. I'm = recently working on a feature to make FreeBSD's IPv4 route have IPv6 address as next-hop = based on Alexander V. Chernikov 's work, and it works so far so good except the = default source address selection. The related RFC is RFC 5549 . >=20 > It wont fix your issue, as once you remove that route your host > wont be able to send anything but link local packets. I am still > unclear why your putting your IP address on lo0 and = attempting/expecting > that address to route over a link that is only configured with LL > addresses. By putting routable IP address to lo0 is just an example. For routers = there may be=20 routable IP addresses on other interface. I'm not able to completely = explain the motivation for such kind of config, but if it is valid to have a LL as next-hop, then it is OK for a router / = host to have one interface with only LL address and also have other routable IP addresses = on other interfaces.=20 >=20 >>=20 >>>>=20 >>>> So it is important if there's corresponding RFC clarify the source = address selection=20 >>>> for IPv4. >>>=20 >>> I do not believe you well find anything that speaks to this issue = for IPv4, as >>> your not really in the situation of RFC6724 which has to do with = multiple IP >>> addresses on the same interface. >>>=20 >>>> Thanks :) >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >>>=20 >>> --=20 >>> Rod Grimes = rgrimes@freebsd.org >>=20 >> Thanks, >> Zhenlei Huang > --=20 > Rod Grimes = rgrimes@freebsd.org Zhenlei Huang