[HN Gopher] Unicast Use of the Formerly Reserved 127/8
       ___________________________________________________________________
        
       Unicast Use of the Formerly Reserved 127/8
        
       Author : todsacerdoti
       Score  : 12 points
       Date   : 2021-11-16 21:13 UTC (1 hours ago)
        
 (HTM) web link (www.ietf.org)
 (TXT) w3m dump (www.ietf.org)
        
       | dtaht wrote:
       | I note the 240/4 and 0/8 and especially zeroth ideas are the more
       | viable of this bunch.
       | 
       | What I mentally see as a possible use for 127/8 (with 127/16
       | still held in reserve) - is the really painfully untransparent
       | string of vm -> container -> OS -> offload engine that we have
       | little insight into today.
        
       | rurcliped wrote:
       | It's common for outbound traffic to 127/8 to be blocked, at the
       | application layer, to prevent SSRF. For example, in WordPress:
       | 
       | https://github.com/WordPress/WordPress/blob/9d4d3f8fba13be09...
        
         | op00to wrote:
         | There are so many embedded systems that assume so much about
         | 127/8. I don't understand what industry is driving this that
         | can't simply look to ipv6...
        
       | toast0 wrote:
       | Contrary to probably most people, I've actually got experience
       | using a lot more than 127.0.0.1. I needed to support an HTTPS
       | service built as a TLS terminating proxy plus an HTTP server on
       | the same machine, the HTTP server didn't understand unix sockets,
       | and the required max connections goal was 1 million; it would
       | have probably been faster and more effective to teach the http
       | server how to do unix sockets or how to do TLS efficiently, but
       | there was organizational opposition to both at the time. Of
       | course, both are now options.
       | 
       | So that means lots of connections on localhost, but you run into
       | difficulties with managing ports unless you listen on multiple
       | ips. Strategically picking the IPs to listen to helps reduce lock
       | contention in the tcp stack as well. IIRC, I think we used
       | 127.0.X.1 (which would be compatible with this proposal), but I
       | no longer have access to the specifics.
       | 
       | The single loopback address of IPv6 is kind of insufficient, but
       | there's not a whole lot of need for IPv6 over localhost, so if I
       | ran into limits, I'd just use IPv4, or even use one of the IPv4
       | in IPv6 space mappings with IPv4 loopback addresses.
       | 
       | OTOH, if they're looking at opening up 127/8, why not also open
       | up 0/8 (other than 0/24) and the class E 240/4 (other than
       | 255.255.255.0/24)? There's some use of class E addresses[1], but
       | I don't think it's that much more of a disruption than 127/8.
       | 
       | [1] Cloudflare uses them as Pseudo addresses for IPv6 transition,
       | and I think I've seen that elsewhere too.
       | https://blog.cloudflare.com/supporting-the-transition-to-ipv...
        
         | schoen wrote:
         | > OTOH, if they're looking at opening up 127/8, why not also
         | open up 0/8 (other than 0/24) and the class E 240/4 (other than
         | 255.255.255.0/24)? There's some use of class E addresses, but I
         | don't think it's that much more of a disruption than 127/8.
         | 
         | That's exactly what we're proposing! This draft is just one of
         | four drafts. The other three are
         | 
         | https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
         | 
         | https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
         | 
         | https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
        
       | schoen wrote:
       | Hey, I'm the lead author of this draft!
       | 
       | As I mentioned below, this is just one of four proposals that
       | we're making at IETF about reclaiming unused IPv4 address space.
       | The other three proposals are
       | 
       | https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
       | 
       | https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
       | 
       | https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
       | 
       | In each case, the address space in question was reserved a long
       | time ago (during the 1980s) for reasons that have not proven
       | necessary or that are no longer applicable.
       | 
       | It is indeed a big undertaking to change this behavior
       | everywhere, but we propose that it will be a gradual process. It
       | turns out that 240/4 is already widely supported (implementers
       | liked the idea when it was previously proposed at IETF in 2008),
       | while we've also gotten patches into Linux for the 0/8 and lowest
       | address behavior, and now in FreeBSD for the lowest address
       | behavior as well. (The lowest address was originally reserved for
       | an "alternative broadcast address" because 4.2BSD chose it as the
       | segment-directed broadcast address in 1983, before there was a
       | standard to say which address to use for this purpose.)
       | 
       | There are lots of other complexities and history that I'm happy
       | to talk about if people are interested.
       | 
       | The amount of IPv4 space still "reserved for future use" in 240/4
       | is 228 addresses, or 1/16 of all of IPv4!
       | 
       | Edit: people who are especially interested in this topic can also
       | watch me presenting on this for 15 minutes at IETF112 last week.
       | 
       | https://youtu.be/cqPVdBvgiXI?t=409
        
       | op00to wrote:
       | Nope.
        
       ___________________________________________________________________
       (page generated 2021-11-16 23:01 UTC)