From owner-freebsd-net@freebsd.org Mon Sep 7 20:48:42 2020 Return-Path: Delivered-To: freebsd-net@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 5EB043D64DE for ; Mon, 7 Sep 2020 20:48:42 +0000 (UTC) (envelope-from SRS0=UtRB=CQ=mail.sermon-archive.info=doug@sermon-archive.info) Received: from mail.sermon-archive.info (sermon-archive.info [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id 4BlgNn2DJ4z3T0W for ; Mon, 7 Sep 2020 20:48:41 +0000 (UTC) (envelope-from SRS0=UtRB=CQ=mail.sermon-archive.info=doug@sermon-archive.info) Received: from [10.0.1.251] (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 4BlgNd5w2Sz2fjQV for ; Mon, 7 Sep 2020 13:48:33 -0700 (PDT) From: Doug Hardie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Address Differences between UDP and SCTP Message-Id: <6A9D0A4B-F35C-4012-A868-5450D60EC13B@mail.sermon-archive.info> Date: Mon, 7 Sep 2020 13:48:33 -0700 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.3445.104.15) X-Virus-Scanned: clamav-milter 0.101.4 at mail X-Virus-Status: Clean X-Rspamd-Queue-Id: 4BlgNn2DJ4z3T0W X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of SRS0=UtRB=CQ=mail.sermon-archive.info=doug@sermon-archive.info designates 71.177.216.148 as permitted sender) smtp.mailfrom=SRS0=UtRB=CQ=mail.sermon-archive.info=doug@sermon-archive.info X-Spamd-Result: default: False [-0.64 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.46)[-0.460]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.71)[-0.713]; DMARC_NA(0.00)[lafn.org: no valid DMARC record]; R_SPF_ALLOW(-0.20)[+ip4:71.177.216.148]; NEURAL_HAM_SHORT(-0.06)[-0.063]; FORGED_SENDER(0.30)[bc979@lafn.org,SRS0=UtRB=CQ=mail.sermon-archive.info=doug@sermon-archive.info]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5650, ipnet:71.177.216.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[bc979@lafn.org,SRS0=UtRB=CQ=mail.sermon-archive.info=doug@sermon-archive.info]; MAILMAN_DEST(0.00)[freebsd-net]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 20:48:42 -0000 I was quite surprised to discover that the sockaddr structure returned = from recv_fd and recvfrom handle IPv4 addresses differently when using = an INET6 socket. I don't know if this was intended, or a side effect. = I started using SCTP because of the need for accessing multi-homed = servers. Some would be on IPv6 and others on IPv4. SCTP handles that = nicely if you use an INET6 socket. When a transaction is received, if = it is to an IPv4 address, then the returned sockaddr will have a = inet_family of IPv4 and the IPv4 structure. If it was sent to an IPv6 = address, then the inet6_family is used. A simple test of the family = tells you which address format was provided and the address is in IPv4 = or IPv6 format accordingly. However, A new site needed to be added and it is behind a NAT router. = The problem with SCTP is that most (possibly all) NAT routers only work = with TCP and UDP. They will not port forward SCTP. So I have no way to = get through to the machine. So I added code to check for that situation = and use UDP instead. This will work because I don't thing it is at all = likely that a machine behind NAT can be multi-homed. However, the code to obtain the remote IP address failed miserably. It = turns out that if you have v6only set to 1, you will never see the IPv4 = packets. If you set it to 0, then you get the packets, but the sockaddr = format with UDP is different than that for SCTP. If it is an IPv6 = address, everything is the same. However, if it is an IPv4 address, = then the family remains IPv6, and the address is in sin6_addr and it is = in the format ::ffff:n.n.n.n. This makes it interesting as I need to = obtain the IPv4 address as part of the verification process that the = transaction is authorized. Was this difference intended, or is it likely to change in the future? -- Doug