Re: is it still nfsen?
I use NTOP. https://www.ntop.org/ Seems much more robust than nfsen. Also, NTOP gives you all sorts of network statistics and lets you slice and dice flows both historically and in real time, all from a single Web console. -mel beckman On Apr 3, 2022, at 7:12 PM, Randy Bush wrote: i am setting up new app/port monitoring. i like nfsen because i can zooom in and see who is sending all that port 43 tls between 11:42 and 12:19. is there some other tool at which i should look? randy
is it still nfsen?
i am setting up new app/port monitoring. i like nfsen because i can zooom in and see who is sending all that port 43 tls between 11:42 and 12:19. is there some other tool at which i should look? randy
Re: V4 via V6 and IGP routing protocols
I'm actually not here to start a debate... happy to learn that the v4 over v6 feature I'm playing with actually exists in another protocol, mainly. I'm critically dependent on source specific routing, also, so I am hoping there's an isis or ospf that can do what I need, or now that I have more routers with enough memory, switch back to an ibgp. Is there a lightweight bgp client worth fiddling with? gobgp looked interesting. Presently I run bird in some places On Sun, Apr 3, 2022 at 6:49 AM Masataka Ohta wrote: > > Dave Taht wrote: > > > Periodically I still do some work on routing protocols. 12? years ago I had > > kind > > of given up on ospf and isis, and picked the babel protocol as an IGP > > for meshy networks because I felt link-state had gone as far as it > > could and somehow unifying BGP DV with an IGP that was also DV > > (distance vector) seemed like a path forward. > > As DV depends other routers to choose the best path from > several candidates updated asynchronously, which means > it is against the E2E principle and decisions by other > routers are delayed a lot to wait all the candidates > are updated, it is hopeless. I like to think babel solved most of the problems that RIP had, and while an optimal state is slow to arrive in babel, a working state is immediate, it's loop free, and it had a rtt metric. > > OTOH, LS only allows routers distribute the current most link > states instantaneously and let end systems of individual > routers compute the best path, LS converges quickly. Ages ago, I'd written a tool to stress out various igps in a scenario where lots of routes were coming and going, called rtod. It pretty much broke all the daemons and protocols I'd had available to me at fairly low levels of churn. https://github.com/dtaht/rtod > BGP is DV because there is no way to describe policies of > various domains and, even if it were possible, most, if > not all, domains do not want to publish their policies > in full detail. yes, and for smaller networks that are interconnecting, bgp can be too heavyweight also. > > > My question for this list is basically, has anyone noticed or fiddled > > with babel? > > No. > > Masataka Ohta -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC
Re: V4 via V6 and IGP routing protocols
On Sun, Apr 3, 2022 at 12:04 PM Mark Tinka wrote: > > > > On 4/3/22 13:55, Dave Taht wrote: > > > Periodically I still do some work on routing protocols. 12? years ago I had > > kind > > of given up on ospf and isis, and picked the babel protocol as an IGP > > for meshy networks because I felt link-state had gone as far as it > > could and somehow unifying BGP DV with an IGP that was also DV > > (distance vector) seemed like a path forward. > > To scale the IGP, we only carry Loopbacks and interfaces (backbone > infrastructure) in the IGP. Many operators have been doing this, for > some time now, as a best pratice. > > Customer routes as well as the DFZ is carried in iBGP. > > The only issue we have hit with this design is hardware that ships with > limited FIB (you're talking 4,000 slots or less). While this can be > mitigated with things like 6PE and RFC 3107, there are, now, tons of > hardware shipping without this physical restriction. For me, the > simpler, the better. > > > > My question for this list is basically, has anyone noticed or fiddled > > with babel? It's supported > > in FRR, bird, and a very small standalone daemon. > > Never heard of it as an IGP until now :-). We'd somewhat foolishly made it a requirement in ietf homenet. it was how hard adding source specific routing to isis turned out to be that turned me. At the time I needed simple means to get ipv6 working on multiple consumer uplinks. That later spawned a now mostly dead attempt to unify ipv4 and ipv6 address distribution called hnet. I'm fiddling with the new ipv4 over ipv6 stuff now in trying to interconnect several ipv4 networks over multiple p2p links. > > Googl'ing: > > https://en.wikipedia.org/wiki/Babel_(protocol) > > > > To recap that: > > > > "V4-via-v6 routing is a routing technique that allows routers with > > only IPv6 addresses (including link-locals) to forward IPv4 packets. > > It doesn't involve encapsulation (tunnelling), it doesn't involve > > translation (NAT), it just works. For details, please see > > Since around Junos 9 (2007), OSPFv3 shipped with the ability to carry > IPv4 NLRI over an IPv6-only network. We never did implement that, as > IS-IS integrated both protocols already. But it's been there for a while > for OSPFv3. > > I don't know when (or if) other vendors implemented the same thing for > OSPFv3. > > That said, nearly any OSPF house I'm aware of still runs both OSPFv2 and > OSPFv3 side-by-side. I guess folk are probably unprepared to use OSPFv3 > for IPv4 NLRI. I'm sad to hear that those two still have to co-exist. I'd given up on how static both routing protocols had become in light of my wireless requirements way back then, also memory requirements. Babel had turned out to be the only way to get teeny routers to route a few thousand ipv6 routes as well as ipv4 over wifi mesh networks. I figured it had made zero penetration outside of that world despite our efforts to get it into frr, bird, etc. > > Mark. -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC
Re: Gmail (thus Nanog) rejecting ipv6 email
> On Apr 3, 2022, at 1:40 PM, na...@shankland.org wrote: > >> It appears that Bjørn Mork said: >>> Google has been trying to move away from Internet email for many years >>> now. Just let them. There is no way you can "fix" that problem on your >>> side. >> >> Don't be silly. Gmail has over a billion users and hosts mail for >> vast numbers of businesses large and small. >> >> I agree that they are stricter than many others at mail authentication >> but considering how big they are, they do a very good job of doing what >> the standards say. Way better than Y**o* ot M*o**. >> > > > Accepting mail for delivery, and then either silently dropping it, delaying > it for days, or putting mail that in no way resembles spam into a spam folder > seems a little worse than “doing what the standards say”. If you’re going to > decide, on little or no evidence, that a message is spam or otherwise does > not deserve to get delivered, the least you could do is to bounce it so that > the sender is aware. No need to generate a bounce mail that could turn into > backscatter; just reject the mail during the SMTP exchange. NO FREAKING KIDDING. I’m running into this with clients for whom we do web site work. Mail not being delivered to Gmail accounts. No bounceback, not being delayed, not marked as spam, just black-holed for no discernible reason. Like, clients losing money because sales leads never make it to them. Extremely frustrating. -Andy
Re: Gmail (thus Nanog) rejecting ipv6 email
It appears that Michael Thomas said: > >On 4/3/22 12:12 PM, Bjørn Mork wrote: >> On a slightly related subject... This DKIM failure surprised me, but at >> least I verified that many NANOG subscribers have mailservers returning >> DMARC failure reports ;-) > >Oh wow, you should report that to Murray. It's on Github, so you can open an issue and if you're feeling inspired a fork and a patch. There's currently 67 open issues and 15 pull requests so don't hold your breath. https://github.com/trusteddomainproject/OpenDKIM R's, John >> Bjørn Mork writes: >> >>> Authentication-Results: mx.google.com; >>> dkim=fail header.i=@mork.no header.s=b header.b=NB0BT8Ez; >>> spf=pass (google.com: best guess record for domain of >>> bj...@miraculix.mork.no >>> designates 2001:41c8:51:8a:feff:ff:fe00:e5 as permitted sender) >>> smtp.mailfrom=bj...@miraculix.mork.no; >>> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mork.no >>> Received: from canardo.dyn.mork.no ([IPv6:2a01:799:c9f:8600:0:0:0:1]) >>> (authenticated bits=0) >>> by louie.mork.no (8.15.2/8.15.2) with ESMTPSA id 233IGnGC342047 >>> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); >>> Sun, 3 Apr 2022 19:16:50 +0100 >>> Received: from miraculix.mork.no >>> ([IPv6:2a01:799:c9f:8602:8cd5:a7b0:d07:d516]) >>> (authenticated bits=0) >>> by canardo.dyn.mork.no (8.15.2/8.15.2) with ESMTPSA id 233IGnKb1147676 >>> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); >>> Sun, 3 Apr 2022 20:16:49 +0200 >>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; >>> t=1649009809; bh=ZByFGHIiZPQYmJjQnCv16CXFZhKG8U3fTayR+Mx3piY=; >>> h=From:To:Cc:Subject:References:Date:Message-ID:From; >>> b=NB0BT8EzJBl2E3jzDaz7QY4C/utMGKFF+HCs8qjQFoHA4JHTD21ZkTk34jp2VOiJ0 >>> pYWHUNXCNaEBK44Hr4U96h5pfXor+dqo0cSuRPTLNnRsoLAQg2kqmQkvylagdeezZc >>> 4p+jQEQv5La2KbjzEIvW6iSGwwe4ltT9hu7h0H8U= >>> Received: (nullmailer pid 389787 invoked by uid 1000); >>> Sun, 03 Apr 2022 18:16:48 - >>> From: =?utf-8?Q?Bj=C3=B8rn_Mork?= >>> To: Randy Bush >>> Cc: John Levine , >>> "North American Network Operators' Group" >>> Subject: Re: Gmail (thus Nanog) rejecting ipv6 email >>> Organization: m >>> References: <875ynqcvsl@miraculix.mork.no> >>> <20220403164123.4ce413a4b...@ary.qy> >>> Date: Sun, 03 Apr 2022 20:16:48 +0200 >>> In-Reply-To: (Randy Bush's message of "Sun, 03 >>> Apr 2022 10:50:06 -0700") >>> Message-ID: <87v8vqav73@miraculix.mork.no> >> >> Did a little testing, and it looks like opendkim create a bogus >> signature if a quoted-string diplay name in a To or Cc headers contains >> an apostrophe. Not good at all.
Re: Gmail (thus Nanog) rejecting ipv6 email
On 4/3/22 12:12 PM, Bjørn Mork wrote: On a slightly related subject... This DKIM failure surprised me, but at least I verified that many NANOG subscribers have mailservers returning DMARC failure reports ;-) Oh wow, you should report that to Murray. Mike Bjørn Mork writes: Authentication-Results: mx.google.com; dkim=fail header.i=@mork.no header.s=b header.b=NB0BT8Ez; spf=pass (google.com: best guess record for domain of bj...@miraculix.mork.no designates 2001:41c8:51:8a:feff:ff:fe00:e5 as permitted sender) smtp.mailfrom=bj...@miraculix.mork.no; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mork.no Received: from canardo.dyn.mork.no ([IPv6:2a01:799:c9f:8600:0:0:0:1]) (authenticated bits=0) by louie.mork.no (8.15.2/8.15.2) with ESMTPSA id 233IGnGC342047 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Sun, 3 Apr 2022 19:16:50 +0100 Received: from miraculix.mork.no ([IPv6:2a01:799:c9f:8602:8cd5:a7b0:d07:d516]) (authenticated bits=0) by canardo.dyn.mork.no (8.15.2/8.15.2) with ESMTPSA id 233IGnKb1147676 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Sun, 3 Apr 2022 20:16:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1649009809; bh=ZByFGHIiZPQYmJjQnCv16CXFZhKG8U3fTayR+Mx3piY=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=NB0BT8EzJBl2E3jzDaz7QY4C/utMGKFF+HCs8qjQFoHA4JHTD21ZkTk34jp2VOiJ0 pYWHUNXCNaEBK44Hr4U96h5pfXor+dqo0cSuRPTLNnRsoLAQg2kqmQkvylagdeezZc 4p+jQEQv5La2KbjzEIvW6iSGwwe4ltT9hu7h0H8U= Received: (nullmailer pid 389787 invoked by uid 1000); Sun, 03 Apr 2022 18:16:48 - From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Randy Bush Cc: John Levine , "North American Network Operators' Group" Subject: Re: Gmail (thus Nanog) rejecting ipv6 email Organization: m References: <875ynqcvsl@miraculix.mork.no> <20220403164123.4ce413a4b...@ary.qy> Date: Sun, 03 Apr 2022 20:16:48 +0200 In-Reply-To: (Randy Bush's message of "Sun, 03 Apr 2022 10:50:06 -0700") Message-ID: <87v8vqav73@miraculix.mork.no> Did a little testing, and it looks like opendkim create a bogus signature if a quoted-string diplay name in a To or Cc headers contains an apostrophe. Not good at all. Bjørn
Re: Gmail (thus Nanog) rejecting ipv6 email
On a slightly related subject... This DKIM failure surprised me, but at least I verified that many NANOG subscribers have mailservers returning DMARC failure reports ;-) Bjørn Mork writes: > Authentication-Results: mx.google.com; > dkim=fail header.i=@mork.no header.s=b header.b=NB0BT8Ez; > spf=pass (google.com: best guess record for domain of bj...@miraculix.mork.no > designates 2001:41c8:51:8a:feff:ff:fe00:e5 as permitted sender) > smtp.mailfrom=bj...@miraculix.mork.no; > dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mork.no > Received: from canardo.dyn.mork.no ([IPv6:2a01:799:c9f:8600:0:0:0:1]) > (authenticated bits=0) > by louie.mork.no (8.15.2/8.15.2) with ESMTPSA id 233IGnGC342047 > (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); > Sun, 3 Apr 2022 19:16:50 +0100 > Received: from miraculix.mork.no ([IPv6:2a01:799:c9f:8602:8cd5:a7b0:d07:d516]) > (authenticated bits=0) > by canardo.dyn.mork.no (8.15.2/8.15.2) with ESMTPSA id 233IGnKb1147676 > (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); > Sun, 3 Apr 2022 20:16:49 +0200 > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; > t=1649009809; bh=ZByFGHIiZPQYmJjQnCv16CXFZhKG8U3fTayR+Mx3piY=; > h=From:To:Cc:Subject:References:Date:Message-ID:From; > b=NB0BT8EzJBl2E3jzDaz7QY4C/utMGKFF+HCs8qjQFoHA4JHTD21ZkTk34jp2VOiJ0 > pYWHUNXCNaEBK44Hr4U96h5pfXor+dqo0cSuRPTLNnRsoLAQg2kqmQkvylagdeezZc > 4p+jQEQv5La2KbjzEIvW6iSGwwe4ltT9hu7h0H8U= > Received: (nullmailer pid 389787 invoked by uid 1000); > Sun, 03 Apr 2022 18:16:48 - > From: =?utf-8?Q?Bj=C3=B8rn_Mork?= > To: Randy Bush > Cc: John Levine , > "North American Network Operators' Group" > Subject: Re: Gmail (thus Nanog) rejecting ipv6 email > Organization: m > References: <875ynqcvsl@miraculix.mork.no> > <20220403164123.4ce413a4b...@ary.qy> > Date: Sun, 03 Apr 2022 20:16:48 +0200 > In-Reply-To: (Randy Bush's message of "Sun, 03 > Apr 2022 10:50:06 -0700") > Message-ID: <87v8vqav73@miraculix.mork.no> Did a little testing, and it looks like opendkim create a bogus signature if a quoted-string diplay name in a To or Cc headers contains an apostrophe. Not good at all. Bjørn
Re: V4 via V6 and IGP routing protocols
On 4/3/22 13:55, Dave Taht wrote: Periodically I still do some work on routing protocols. 12? years ago I had kind of given up on ospf and isis, and picked the babel protocol as an IGP for meshy networks because I felt link-state had gone as far as it could and somehow unifying BGP DV with an IGP that was also DV (distance vector) seemed like a path forward. To scale the IGP, we only carry Loopbacks and interfaces (backbone infrastructure) in the IGP. Many operators have been doing this, for some time now, as a best pratice. Customer routes as well as the DFZ is carried in iBGP. The only issue we have hit with this design is hardware that ships with limited FIB (you're talking 4,000 slots or less). While this can be mitigated with things like 6PE and RFC 3107, there are, now, tons of hardware shipping without this physical restriction. For me, the simpler, the better. My question for this list is basically, has anyone noticed or fiddled with babel? It's supported in FRR, bird, and a very small standalone daemon. Never heard of it as an IGP until now :-). Googl'ing: https://en.wikipedia.org/wiki/Babel_(protocol) To recap that: "V4-via-v6 routing is a routing technique that allows routers with only IPv6 addresses (including link-locals) to forward IPv4 packets. It doesn't involve encapsulation (tunnelling), it doesn't involve translation (NAT), it just works. For details, please see Since around Junos 9 (2007), OSPFv3 shipped with the ability to carry IPv4 NLRI over an IPv6-only network. We never did implement that, as IS-IS integrated both protocols already. But it's been there for a while for OSPFv3. I don't know when (or if) other vendors implemented the same thing for OSPFv3. That said, nearly any OSPF house I'm aware of still runs both OSPFv2 and OSPFv3 side-by-side. I guess folk are probably unprepared to use OSPFv3 for IPv4 NLRI. Mark.
Re: Gmail (thus Nanog) rejecting ipv6 email
On Apr 3, 2022, at 9:41 AM, John Levine wrote: > > It appears that Bjørn Mork said: >> Google has been trying to move away from Internet email for many years >> now. Just let them. There is no way you can "fix" that problem on your >> side. > > Don't be silly. Gmail has over a billion users and hosts mail for > vast numbers of businesses large and small. > > I agree that they are stricter than many others at mail authentication > but considering how big they are, they do a very good job of doing what > the standards say. Way better than Y**o* ot M*o**. > Accepting mail for delivery, and then either silently dropping it, delaying it for days, or putting mail that in no way resembles spam into a spam folder seems a little worse than “doing what the standards say”. If you’re going to decide, on little or no evidence, that a message is spam or otherwise does not deserve to get delivered, the least you could do is to bounce it so that the sender is aware. No need to generate a bounce mail that could turn into backscatter; just reject the mail during the SMTP exchange. Jim Shankland
Re: Gmail (thus Nanog) rejecting ipv6 email
Randy Bush writes: > i try to keep a list of goog's ipv6 email space and don't deliver to it; > rather using ipv4 instead. unfortunately, goog does not cooperate with > dnswl.org, so this can not be automated. How about using their SPF records as automation input? Their MXes are inside those blocks right now at least. Bjørn
Re: Gmail (thus Nanog) rejecting ipv6 email
i try to keep a list of goog's ipv6 email space and don't deliver to it; rather using ipv4 instead. unfortunately, goog does not cooperate with dnswl.org, so this can not be automated. this is mildly damaging to the ipv6 religion, but i don't let that spoil my coffee. their lack of cooperation with the dns good list means inbound from them gets dropped when one of their outbound smtp senders gets badlisted, which they often do. i do not let that spoil my coffee either. i would not want to work for goog's email service; too much pain. randy
Re: Gmail (thus Nanog) rejecting ipv6 email
It appears that Bjørn Mork said: >Google has been trying to move away from Internet email for many years >now. Just let them. There is no way you can "fix" that problem on your >side. Don't be silly. Gmail has over a billion users and hosts mail for vast numbers of businesses large and small. I agree that they are stricter than many others at mail authentication but considering how big they are, they do a very good job of doing what the standards say. Way better than Y**o* ot M*o**. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Re: V4 via V6 and IGP routing protocols
Dave Taht wrote: Periodically I still do some work on routing protocols. 12? years ago I had kind of given up on ospf and isis, and picked the babel protocol as an IGP for meshy networks because I felt link-state had gone as far as it could and somehow unifying BGP DV with an IGP that was also DV (distance vector) seemed like a path forward. As DV depends other routers to choose the best path from several candidates updated asynchronously, which means it is against the E2E principle and decisions by other routers are delayed a lot to wait all the candidates are updated, it is hopeless. OTOH, LS only allows routers distribute the current most link states instantaneously and let end systems of individual routers compute the best path, LS converges quickly. BGP is DV because there is no way to describe policies of various domains and, even if it were possible, most, if not all, domains do not want to publish their policies in full detail. My question for this list is basically, has anyone noticed or fiddled with babel? No. Masataka Ohta
V4 via V6 and IGP routing protocols
Periodically I still do some work on routing protocols. 12? years ago I had kind of given up on ospf and isis, and picked the babel protocol as an IGP for meshy networks because I felt link-state had gone as far as it could and somehow unifying BGP DV with an IGP that was also DV (distance vector) seemed like a path forward. My question for this list is basically, has anyone noticed or fiddled with babel? It's supported in FRR, bird, and a very small standalone daemon. Anyway, after babel hit the ietf, development slowed down a lot, but along the way some useful innovations were made, notably a RTT metric, "source specific routing" for ipv6, HMAC authentication, and most recently, Juliusz's announcement of V4-via-v6 hit the git babeld codebase. To recap that: "V4-via-v6 routing is a routing technique that allows routers with only IPv6 addresses (including link-locals) to forward IPv4 packets. It doesn't involve encapsulation (tunnelling), it doesn't involve translation (NAT), it just works. For details, please see https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6 Short story: v4viav6 is enabled by default if your linux kernel is recent enough. Just upgrade babeld to current master, and you should see your v6-only routers forward IPv4 packets. In order to disable announcing of v4-via-v6 routes, add the following to your configuration file: default v4-via-v6 false Long story. There are two pieces to v4-via-v6: installing IPv4 routes with an IPv6 next hop, and announcing such routes. By default, babeld will: - install v4-via-v6 routes on Linux 5.2 and later; - announce v4-via-v6 routes on Linux 5.13 and later. (backports are available for various stable versions) The former behaviour cannot be overridden -- we always install v4-via-v6 routes if the kernel supports them, and (obviously) never do otherwise. The latter behaviour can be overridden by the interface option 'v4-via-v6'. Feel free to experiment, but be aware that enabling v4-via-v6 on an older kernel might create ICMP blackholes. Please let me know if you feel that it should be possible to completely disable v4-via-v6 even on newer kernels, and whether you feel that v4-via-v6 should be disabled by default. (The "Security Considerations" section of the draft cited above might be interesting.)" Enjoy, -- Juliusz Juliusz Chroboczek via alioth-lists.debian.net Thu, Mar 31, 3:30 PM (3 days ago) to babel-users, Théophile On Fri, Apr 1, 2022 at 2:17 AM Pascal Thubert (pthubert) via NANOG wrote: > > A very long thread. > > Face it: everyone is right, and even technically correct. There's no good and > evil. We'd know, after 20 years. > > I live in France and my country has a famous 100-years war in its long > history with England. Do we want to beat this here? > > The plain truth: > > - IPv4 is here to stay. Some v4-only nodes and functionalities are here to > stay. Plenty of reasons for that in this thread. > - IPv6 is unavoidable. New devices like phones and IOT need it, many IPv6 > only in that space, numbers only growing > > > The things everyone agrees upon: > - Dual stack everywhere and forever is the worst of both worlds as it doubles > every cost, and that will remain long as the war rages > - Stateful NATs the size of the Internet not doable, which in my book says > that isolation not only unavoidable but already there. > > An the illusions: > > - any-to-any is required. In particular, any IPv4-only to any-IPv6 only. I'm > not talking security but plain functionality. And yes, exceptions if they are > few can be handled by expensive stateful NATs when the cost is justified > - the Internet is a big homogenous thing. The more it expands, the more we > see domains forming where specific capabilities are deployed, and because we > fail to handle that at L3, we mask the functionalities above UDP. > > If we agree on the above then a compromise is possible. Ideally, the > compromise would: > - maintain the current state of v4 affairs for those who want that > - scale v4 addresses for those who want that > - provide v4 to v6 stateless NATs for this who want that, and > - allow networks to be either of the 2 versions for those who want that. > > SciFi? There's a proposed starting point for that compromise in the yada-yatt > draft published at IETF v6ops. The key is to use baby steps between locations > (in the transition plan) where people can be at ease and stay as long as they > want to, as opposed to enforcing a giant zero-to-hero illusionary step. > > Are you ready for that, or should we wait another 80 years with dual stack > and gigantic stateful NATs? > > Pascal > > > > > -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC
Re: Gmail (thus Nanog) rejecting ipv6 email
I didn't know anyone still cared? Google has been trying to move away from Internet email for many years now. Just let them. There is no way you can "fix" that problem on your side. If you care about specific recipients, then inform them that Google randomly throws away some of their legitimate email. Send a paper mail or phone them if necessary. That's pretty much all you can do. If those recipients continue to use gmail, then that's their decision and problem. I assume NANOG is informed about this now. Bjørn
Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)
Looks like Honeywell will be affected. On Sat, Apr 2, 2022, 5:11 PM John Curran wrote: > NANOGers - > > As previously reported here, ARIN will be shutting down the ARIN-NONAUTH > IRR database on *Monday, 4 April 2022 at 12:00 PM ET.* > > It is quite likely that some network operators will see different route > processing as a result of this change, as validation against the > ARIN-NONAUTH IRR database will not longer be possible. > > Please be aware of this upcoming event and *make alternative arrangements > if you are presently relying on upon routing objects in the ARIN-NONAUTH > IRR database.* > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > Begin forwarded message: > > *From: *John Curran > *Subject: **TIMELY - IMPORTANT NOTICE - Retirement of ARIN > Non-Authenticated IRR scheduled for 4 April 2022* > *Date: *25 March 2022 at 7:26:06 PM EDT > *To: *nanog list > > NANOGers - > > Please take note of the following event that will take place in less than > 10 days time - *ARIN will shut down the ARIN-NONAUTH IRR database on > Monday, 4 April 2022 at 12:00 PM ET* > > Any networks relying on upon routing objects in the ARIN-NONAUTH IRR > database should be actively working on alternative arrangements. > > > If you have questions about this transition or need any assistance, you > can contact ARIN by: > > • Submitting an Ask ARIN ticket or chat with us using your ARIN Online > account > • emailing the Routing Security Team at routing.secur...@arin.net > • contacting the Registration Services Help Desk by phone Monday through > Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660 > > > Thank you! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > Begin forwarded message: > > *From: *John Curran > *Subject: **IMPORTANT NOTICE - Retirement of ARIN Non-Authenticated IRR > rescheduled for 4 April 2022* > *Date: *16 February 2022 at 4:33:24 PM EST > *To: *NANOG Operators' Group > > NANOGers - > > An important reminder – On 4 April 2022, ARIN's non-authenticated Internet > Routing Registry (IRR) will be retired. > > Please review the attached notice for details, and do not hesitate to > contact ARIN if you have any questions about this transition or need > assistance. > > I ask that you do not hesitate to forward this notice to any others you > know that are potentially unaware & impacted by this important transition. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > Begin forwarded message: > > *From: *ARIN > *Subject: **[arin-announce] UPDATE: Retirement of ARIN Non-Authenticated > IRR rescheduled for 4 April 2022* > *Date: *28 January 2022 at 9:01:07 PM GMT+4 > *To: *"arin-annou...@arin.net" > > This announcement is to inform you that the retirement of the ARIN > non-authenticated Internet Routing Registry (IRR) has been rescheduled to 4 > April 2022 at 12:00 PM EST. After this time, users will no longer be able > to create, update, or delete records in the ARIN-NONAUTH database, and the > ARIN-NONAUTH data stream will no longer be available in Near Real Time > Mirroring (NRTM) or via FTP or Whois Port 43. This date change is being > made in order to ensure that the first day after retirement does not fall > on a Friday. > > The following information is from the initial announcement: > > ARIN has been engaged in a multi-year project to create and deploy a new > and improved Internet Routing Registry (IRR). As a result of these efforts, > ARIN now provides users with the ability to create, update, and delete > objects in ARIN’s authenticated IRR database using ARIN Online or ARIN’s > RESTful API. Unfortunately, use of ARIN’s previous non-authenticated > email-based IRR service actually increased after ARIN released its > authenticated IRR, in opposition to the outcome ARIN anticipated when > improving its IRR. > > On 8 February 2021, ARIN held a consultation to solicit input on the > retirement of ARIN’s non-authenticated email-based IRR service. This > retirement was originally scheduled for 30 September 2021. Based on > community input, the proposed date for the ARIN-NONAUTH retirement was > delayed to 31 March 2022 to allow more transition time for users. We also > notified by email Points of Contact (POCs) of organizations who have > objects in the ARIN-NONAUTH database of the retirement date and offered > them our assistance with the transition. > > If you have questions about this transition or need assistance, you can > contact us by: > > • submitting an Ask ARIN ticket or chat with us using your ARIN Online > account > • emailing the Routing Security Team at routing.secur...@arin.net > • contacting the Registration Services Help Desk by phone Monday through > Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660 > > Regards, > > Brad Gorman > Senior Product Owner, Routing Security > American Registry for Internet Numbers (ARIN) > > > > >
Re: V6 still not supported
Matthew Petach wrote: Hi Masataka, Hi, One quick question. If every host is granted a range of public port numbers on the static stateful NAT device, what happens when two customers need access to the same port number? I mean static outgoing port number, but your concern should be well known incoming port number, which is an issue not specific to "static stateful" NAT. Because there's no way in a DNS NS entry to specify a port number, if I need to run a DNS server behind this static NAT, I *have* to be given port 53 in my range; there's no other way to make DNS work. And SMTP, as is explained in draft-ohta-e2e-nat-00: A server port number different from well known ones may be specified through mechanisms to specify an address of the server, which is the case of URLs. However, port numbers for DNS and SMTP are, in general, implicitly assumed by DNS and are not changeable. Or, a NAT gateway may receive packets to certain ports and behave as an application gateway to end hosts, if request messages to the server contains information, such as domain names, which is the case with DNS, SMTP and HTTP, to demultiplex the request messages to end hosts. However, for an ISP operating the NAT gateway, it may be easier to operate independent servers at default port for DNS, SMTP, HTTP and other applications for their customers than operating application relays. Though the draft is for E2ENAT, situation is same for any kind of NAT. This means that if I have two customers that each need to run a DNS server, I have to put them on separate static NAT boxes--because they can't both get access to port 53. See above for other possibilities. This limits the effectiveness of a stateful static NAT box For incoming port, static stateful NAT is no worse than dynamic NAT. Both may be configured to map certain incoming ports to certain local ports and addresses statically or dynamically with, say, UPnP. The point of static stateful NAT is for outgoing port that it does not require logging. tl;dr -- "if only we'd thought of putting a port number field in the NS records in DNS back in 1983..." And, MX. As named has "-p" option, I think some people were already aware of uselessness of the option in 1983. But, putting a port number field at that time is overkill. Masataka Ohta
