Re: if not v6, what?
> On Sep 7, 2021, at 19:51 , Masataka Ohta > wrote: > > Niels Bakker wrote: > >>> As for well known port, we can specify non-default port numbers >>> in URLs (I'm not sure whether it works for mailto: or not) or. >>> in the future, things like DNS SRV RRs should be helpful. >> This absolutely doesn't work. > > Thank you very much for your emotional and unfounded > comment. It’s neither. There’s no support for SRV RRs in virtually any of the software that would need it in order for this to be a viable solution and it does not appear to be coming any time soon. That’s a fact. Not unfounded and not emotional. You, yourself admit that mailto: URLs don’t have space for a port number (though you express uncertainty, I assure you that they don’t). >> And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email). > > I know SRV and other similar proposals so far are not > very compatible with URL syntax and should better be > simplified. I think the bigger problem is that SRV just hasn’t really caught on and I suspect isn’t likely to. In reality, the effort to modify all the code to support SRV wouldn’t be significantly less than what is required to do IPv6 which would (mostly) obviate the need for SRV as service-specific IP addresses would be easy to assign. The significant problem here, no matter how many different ways we attempt to hack around it is address shortage. The solution to that is more addresses (i.e. IPv6). >>> Then, to run servers at home, we only need some not-well-known >>> ports forwarded, which can be default or value added service of >>> your local ISP, just like fixed IP addresses today. > >> Oh and we need to work around the whole IP reputation system that governs >> email today. > IP reputation system must evolve to be IP+port reputation > system, which is not my problem. ROFLMAO — as if that’s at all likely to happen. Further, you have the problem that the port side where this matters is ephemeral meaning that multiple systems (which need different reputations) share the same source address+port combination, so it doesn’t really help. No, IP reputation system must evolve to support 128 bit addresses and some level of heuristic determination of how many of those 128 bits should be applied to a given reputation (probably defaulting to 64 and working left from there). Owen
Re: if not v6, what?
Mark Andrews wrote: I know SRV and other similar proposals so far are not very compatible with URL syntax and should better be simplified. The only thing difficult to map was non-default ports and that could easily have been addressed. That's why simplification is desired. See below. Remember SRV required a seperate RFC to specify how to map existing services on to it. HTTPS just prefixed the label "_”. That could have easily been done with SRV. HTTPS and SVBC are just SRV on steroids. Nothing should be HTTPS specific. What is essentially necessary is to map: :["@"] and :["@"]":" to :["@"]":" and :["@"]":" for which RRs like: _. MAP should be just enough. But if you insist, UPnP by Microsoft has been implemented on almost all NAT boxes. There even exists PCP. But how much has been implemented in CGNs and how many ISP’s enable it if it is implemented? As most users are satisfied without port forwarding and even those who aren't merely need static configuration on CGNs, why do you bother? > Getting IPv4 continue to work > just add layer upon layer of hacks which we are all continuing > to pay for. We don't need any new mechanism to keep using IPv4 if users can accept external servers, which is the usual case for SMTP and DNS. On the other hand, people still insisting on IPv6 are, as you can see here, still arguing for hacks, most of which are well known and already abandoned but, worse, some of which are new. Masataka Ohta
Re: if not v6, what?
> On 8 Sep 2021, at 12:51, Masataka Ohta > wrote: > > Niels Bakker wrote: > >>> As for well known port, we can specify non-default port numbers >>> in URLs (I'm not sure whether it works for mailto: or not) or. >>> in the future, things like DNS SRV RRs should be helpful. >> This absolutely doesn't work. > > Thank you very much for your emotional and unfounded > comment. > >> And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email). Which is why there is HTTPS and SVCB. If you look at your recursive server logs you are likely to see queries for HTTPS being made as browsers are starting to make queries for HTTPS (a.k.a. TYPE65). > I know SRV and other similar proposals so far are not > very compatible with URL syntax and should better be > simplified. The only thing difficult to map was non-default ports and that could easily have been addressed. Remember SRV required a seperate RFC to specify how to map existing services on to it. HTTPS just prefixed the label "_”. That could have easily been done with SRV. HTTPS and SVBC are just SRV on steroids. >>> Then, to run servers at home, we only need some not-well-known >>> ports forwarded, which can be default or value added service of >>> your local ISP, just like fixed IP addresses today. > >> Oh and we need to work around the whole IP reputation system that governs >> email today. > IP reputation system must evolve to be IP+port reputation > system, which is not my problem. > >> Is there even any IETF work being done on getting port forwards on a device >> behind your immediate LAN at home? > > That's overkill, because servers should have stable > addresses and ports. So, we only need statically > configured port forwarding. > > But if you insist, UPnP by Microsoft has been implemented > on almost all NAT boxes. There even exists PCP. But how much has been implemented in CGNs and how many ISP’s enable it if it is implemented? Getting IPv4 continue to work just add layer upon layer of hacks which we are all continuing to pay for. While we debate more and more services are enabling IPv6 and the traffic is shifting to IPv6. >> Do you have any more practical proposals, or..? > > What are missing are practical comments. > > Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: if not v6, what?
Niels Bakker wrote: As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful. This absolutely doesn't work. Thank you very much for your emotional and unfounded comment. And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email). I know SRV and other similar proposals so far are not very compatible with URL syntax and should better be simplified. Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today. Oh and we need to work around the whole IP reputation system that governs email today. IP reputation system must evolve to be IP+port reputation system, which is not my problem. Is there even any IETF work being done on getting port forwards on a device behind your immediate LAN at home? That's overkill, because servers should have stable addresses and ports. So, we only need statically configured port forwarding. But if you insist, UPnP by Microsoft has been implemented on almost all NAT boxes. There even exists PCP. Do you have any more practical proposals, or..? What are missing are practical comments. Masataka Ohta
Re: fun with ports, was if not v6, what?
It appears that Niels Bakker said: >Is there even any IETF work being done on getting port forwards on a >device behind your immediate LAN at home? Have you looked at RFCs 6887 and 6970? R's, John
Re: if not v6, what?
* mo...@necom830.hpcl.titech.ac.jp (Masataka Ohta) [Tue 07 Sep 2021, 18:36 CEST]: As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful. This absolutely doesn't work. And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email). Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today. Oh and we need to work around the whole IP reputation system that governs email today. Is there even any IETF work being done on getting port forwards on a device behind your immediate LAN at home? We may even develop transport protocols with 32 bit port numbers, which is a lot easier to deploy than IPv6. Do you have any more practical proposals, or..? -- Niels.
Re: if not v6, what?
Michael Thomas wrote: I looked up CGN's this morning and the thing that struck me the most was losing port forwarding. It's probably a small thing to most people but losing it means to get an incoming session it always has to be mediated by something on the outside. So, to receive mails at home, we need forwarding of well known SMTP port (25) or an external SMTP server. So is there anything we could have done different? As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful. Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today. > Even if we bolted two more bytes onto an IPv4 address > and nothing more, would that have been adopted either? Nothing more? We may even develop transport protocols with 32 bit port numbers, which is a lot easier to deploy than IPv6. Masataka Ohta
Re: if not v6, what?
On 9/7/21 17:25, Eric Kuhnke wrote: The vast majority of LTE based last mile users in developing nation environments (where maybe less than 5% of people have residential wireline broadband to their residence) are already behind a cgnat. Our mobile carriers in Africa, for example, will happily give the vendors 10's of millions of coin every year, to maintain CG-NAT. It's truly amazing, how much money they are swimming in. The bad news is that infrastructure is no longer a play, and by the time they realize this, they'll have wished they at least used that cash to buy their staff cookies. In many places it's actually an anomaly and weird for a person to desire, or be able to afford, both a broadband internet connection at home with wired router/801.11 AP, and also the (per GB) data service for their cellphone. They choose to go with only the latter. Well, in many cases, it comes down to what is available (even before it's affordable). We all NEED phones, but we don't all NEED fibre at the house (I'm generalizing, but you know what I mean). The phone is probably the most basic requirement, and is what operators are most likely to accommodate for before they add wire for data. So chances are folk have started off with a phone. If the fibre follows, is it affordable, to the point that it can co-exist (not replace) my phone? Mark.
Re: if not v6, what?
The vast majority of LTE based last mile users in developing nation environments (where maybe less than 5% of people have residential wireline broadband to their residence) are already behind a cgnat. In many places it's actually an anomaly and weird for a person to desire, or be able to afford, both a broadband internet connection at home with wired router/801.11 AP, and also the (per GB) data service for their cellphone. They choose to go with only the latter. On Sun, Sep 5, 2021 at 6:00 PM Grant Taylor via NANOG wrote: > On 9/5/21 3:28 PM, Michael Thomas wrote: > > I looked up CGN's this morning and the thing that struck me the most was > > losing port forwarding. It's probably a small thing to most people but > > losing it means to get an incoming session it always has to be mediated > > > by something on the outside. Yuck. So I hope that is not what the future > > hold, though it probably does. > > I think we are heading into a world where Internet is going to be > bifurcated with "/on/ the Internet" (with globally routed IP > address(es)) or "/access/ /to/ the Internet" (with one or more layers of > CGN). > > I think that the vast majority of consumers would be content with the > latter while a small minority will demand the former. > > Content hosting will almost definitely require the former. (Wiggle room > is for other arrangements that can be made.) > > > > -- > Grant. . . . > unix || die > >
Re: if not v6, what?
On 9/5/21 3:28 PM, Michael Thomas wrote: I looked up CGN's this morning and the thing that struck me the most was losing port forwarding. It's probably a small thing to most people but losing it means to get an incoming session it always has to be mediated by something on the outside. Yuck. So I hope that is not what the future hold, though it probably does. I think we are heading into a world where Internet is going to be bifurcated with "/on/ the Internet" (with globally routed IP address(es)) or "/access/ /to/ the Internet" (with one or more layers of CGN). I think that the vast majority of consumers would be content with the latter while a small minority will demand the former. Content hosting will almost definitely require the former. (Wiggle room is for other arrangements that can be made.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature
if not v6, what?
On 9/4/21 10:43 PM, Saku Ytti wrote: I view IPv6 as the biggest mistake of my career and feel responsible for this horrible outcome and I do apologise to Internet users for it. This dual-stack is the worst possible outcome, and we've been here over two decades, increasing cost and reducing service quality. We should have performed better, we should have been IPv6 only years ago. I wish 20 years ago big SPs would have signed a contract to drop IPv4 at the edge 20 years from now, so that we'd given everyone a 20 year deadline to migrate away. 20 years ago was the best time to do it, the 2nd best time is today. If we don't do it, 20 years from now, we are in the same position, inflating costs and reducing quality and transferring those costs to our end users who have to suffer from our incompetence. I can't see how an "end of the tunnel" clause would be helpful. As with everything, nothing would be done until the very and then they'd just extend the tunnel again which is functionally no different than running out of IP address. I looked up CGN's this morning and the thing that struck me the most was losing port forwarding. It's probably a small thing to most people but losing it means to get an incoming session it always has to be mediated by something on the outside. Yuck. So I hope that is not what the future hold, though it probably does. So is there anything we could have done different? Was this ever really a technical issue? Even if we bolted two more bytes onto an IPv4 address and nothing more, would that have been adopted either? Mike
