Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Tom Hill]

On 20/11/2021 19:59, Michael Thomas wrote:
> but starving the beast doesn't have a great track record. We are talking
> about 20% of the address space that's being wasted so it's not nothing.

Starving the beast is actively working to make IPv4 cost-prohibitive. I
only wish those whom Jay refers to, had fewer addresses to buy & sell -
definitely not more.

There are ~4.3B addresses in the entire 32-bit IPv4 space, and there are
~4.3B /64s in every IPv6 /32.

The D/E IPv4 space would make speculators rich, nothing else of note.

-- 
Tom

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Greg Skinner via NANOG]

> On Nov 24, 2021, at 5:08 PM, William Herrin  wrote:
> 
> On Wed, Nov 24, 2021 at 4:36 PM David Conrad  wrote:
>>> I like research but what would the RIRs study? The percentage of the
>> 
>> Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC
>> and they said similar things when 1.1.1.0/24 was stood up as an
>> experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.
> 
> Hi David,
> 
> I don't recall there being any equipment or software compatibility
> concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As
> I recall it, there were concerns with prior local use and potential
> trash traffic. It seemed likely those concerns could be addressed with
> experiments, and the experiments in fact addressed them.
> 
> The prior local use worry reared its head again with 240/4 but given
> the prior experience with 1.0.0.0/8 I don't personally believe we need
> to re-run that experiment just because the numbers are part of a
> different block.
> 
> 
>> Seems to me that a number of folks on this list and during this
>> discussion would disagree with a blanket assertion that 240/4
>> is “dysfunctional on the 2021 Internet” - some of them even
>> wrote a draft discussing the possibility.
> 
> Line them up. Show of hands. Who really thinks that if we assign
> 240.0.0.1 to a customer tomorrow without waiting for anyone to clean
> up their software and hardware, you won't get enough complaints about
> things not working that you have to take it back and assign a
> different address instead?
> 
> 
>> 1. Move 240/4 from "reserved" to "unallocated unicast"
>> 
>> OK, but this seems like a quibble.  The status for 240/4 is “
>> RESERVED: designated by the IETF for specific non-global-unicast
>> purposes as noted.”  The “as noted” part is “Future Use”.
> 
> It's not a quibble. Some vendors take the current status to mean
> "treat it like unicast until we're told otherwise." Others take the
> status to mean, "packets with these addresses are bogons without a
> defined routing behavior until we're told otherwise." The result is
> incompatible behavior between vendors. Changing that direction to
> "treat it like unicast" without ambiguity is not a quibble.
> 
> Regards,
> Bill Herrin
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

For what it’s worth, I’ve been tracking this issue on other netops mailing 
lists.  There is a recent post on the LACNOG list from Leandro Bertholdo 
 
referencing 
https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ 
, 
a draft proposing another way to make additional IPv4 address space available.  
I haven’t had time to read the draft closely, but I noticed that it involves 
the use of 240/4.  Subsequent googling about the draft turned up a presentation 
 
describing how the techniques described could be deployed.  I noticed that the 
presentation made reference to OpenWRT, so perhaps the authors are aware of the 
work that the authors of the IPv4 Unicast Extensions Project have done in that 
area.

The adaptive-ipv4 draft will expire sometime next month, so anyone interested 
in seeing it move forward should contact the authors.

—gregbo

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Denis Fondras]

Le Wed, Nov 24, 2021 at 05:08:43PM -0800, William Herrin a écrit :
> I don't recall there being any equipment or software compatibility
> concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. 

Perhaps not the whole /8 but definitely some buggy implementations :
https://seclists.org/nanog/2018/Apr/52

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[William Herrin]

On Wed, Nov 24, 2021 at 4:36 PM David Conrad  wrote:
>> I like research but what would the RIRs study? The percentage of the
>
> Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC
> and they said similar things when 1.1.1.0/24 was stood up as an
> experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

Hi David,

I don't recall there being any equipment or software compatibility
concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As
I recall it, there were concerns with prior local use and potential
trash traffic. It seemed likely those concerns could be addressed with
experiments, and the experiments in fact addressed them.

The prior local use worry reared its head again with 240/4 but given
the prior experience with 1.0.0.0/8 I don't personally believe we need
to re-run that experiment just because the numbers are part of a
different block.


> Seems to me that a number of folks on this list and during this
> discussion would disagree with a blanket assertion that 240/4
> is “dysfunctional on the 2021 Internet” - some of them even
> wrote a draft discussing the possibility.

Line them up. Show of hands. Who really thinks that if we assign
240.0.0.1 to a customer tomorrow without waiting for anyone to clean
up their software and hardware, you won't get enough complaints about
things not working that you have to take it back and assign a
different address instead?


> 1. Move 240/4 from "reserved" to "unallocated unicast"
>
> OK, but this seems like a quibble.  The status for 240/4 is “
> RESERVED: designated by the IETF for specific non-global-unicast
> purposes as noted.”  The “as noted” part is “Future Use”.

It's not a quibble. Some vendors take the current status to mean
"treat it like unicast until we're told otherwise." Others take the
status to mean, "packets with these addresses are bogons without a
defined routing behavior until we're told otherwise." The result is
incompatible behavior between vendors. Changing that direction to
"treat it like unicast" without ambiguity is not a quibble.

Regards,
Bill Herrin

--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[David Conrad]

Bill,

On Nov 23, 2021, at 11:12 PM, William Herrin  wrote:
>> 1. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time (a year or two?).
> 
> I like research but what would the RIRs study? The percentage of the
> 2021 Internet reachable from a station assigned a 240/4 IP address?
> Suppose it's 95%? Or 50%? Is there a difference? Neither one is enough
> to deploy the addresses for 2021 global use.

Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC and 
they said similar things when 1.1.1.0/24 was stood up as an experiment by 
Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

>> 5. Armed with hard data on the usability of the 240/4 /8s
>> allocated, people can scream past each other much more
>> authoritatively on the topic of what to do with 240/4.
> 
> Which is not particularly valuable. We already know the addresses are
> dysfunctional on the 2021 Internet. There's no credible disagreement
> on that point.

Seems to me that a number of folks on this list and during this discussion 
would disagree with a blanket assertion that 240/4 is “dysfunctional on the 
2021 Internet” - some of them even wrote a draft discussing the possibility. 

>> 2. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time
> 
> But that still starts with:
> 
>> 1. Move 240/4 from "reserved" to "unallocated unicast"

OK, but this seems like a quibble.  The status for 240/4 is “ RESERVED: 
designated by the IETF for specific non-global-unicast purposes as noted.”  The 
“as noted” part is “Future Use”.  As far as I’m aware, “future use” would not 
preclude “experimental use” however if it makes people feel better to have an 
IANA considerations section that says the prefixes need to be moved to 
ALLOCATED, I struggle to see how that would be a problem.

Regards,
-drc

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[William Herrin]

On Tue, Nov 23, 2021 at 9:02 PM David Conrad  wrote:
> On Nov 23, 2021, at 10:33 AM, William Herrin  wrote:
> > 1. Move it from "reserved" to "unallocated unicast" (IETF action)
>
> Or…
>
> 1. IAB or IESG requests the IANA team to delegate one of
> the 240/4 /8s to the RIRs on demand for experimental
> purposes for a fixed period of time (a year or two?).

Hi David,

I like research but what would the RIRs study? The percentage of the
2021 Internet reachable from a station assigned a 240/4 IP address?
Suppose it's 95%? Or 50%? Is there a difference? Neither one is enough
to deploy the addresses for 2021 global use.

> 5. Armed with hard data on the usability of the 240/4 /8s
> allocated, people can scream past each other much more
> authoritatively on the topic of what to do with 240/4.

Which is not particularly valuable. We already know the addresses are
dysfunctional on the 2021 Internet. There's no credible disagreement
on that point. We don't particularly need to know it more
authoritatively. What we need to know more authoritatively is: IF we
tell vendors and operators to expect those addresses to come into use
and alter their equipment and configurations accordingly, -how long-
will it be until the addresses are usable on the Internet. 2026? 2031?
2051? That research could be valuable, but it can't usefully start
until:

> 1. Move 240/4 from "reserved" to "unallocated unicast"

So maybe instead of

> 2. Wait 10 years

It's

> 2. IAB or IESG requests the IANA team to delegate one of
> the 240/4 /8s to the RIRs on demand for experimental
> purposes for a fixed period of time

But that still starts with:

> 1. Move 240/4 from "reserved" to "unallocated unicast"

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[David Conrad]

On Nov 23, 2021, at 10:33 AM, William Herrin  wrote:
> On Tue, Nov 23, 2021 at 5:03 AM Eliot Lear  wrote:
>> So what's the road to actually being able to use [240/4]?
> 
> 1. Move it from "reserved" to "unallocated unicast" (IETF action)
> 2. Wait 10 years
> 3. Now that nearly all equipment that didn't treat it as
> yet-to-be-allocated unicast has cycled out of use, argue about what to
> allocate the addresses to for best effect.

Or…

1. IAB or IESG requests the IANA team to delegate one of the 240/4 /8s to the 
RIRs on demand for experimental purposes for a fixed period of time (a year or 
two?). 
2. The RIRs, with input from their communities, formulate research programs to 
explore the viability of the space they have just received for “normal” unicast 
space.
3. The RIRs assign that space in accordance with those research programs.
4. At the end of the fixed period of time, research reports are published.
5. Armed with hard data on the usability of the 240/4 /8s allocated, people can 
scream past each other much more authoritatively on the topic of what to do 
with 240/4.

> Bottom line though is that the IETF has to act before anyone else
> reasonably can.


To be honest, I don’t think it actually matters if it is the IAB, the IESG, or 
the NRO that directs the IANA to do stuff (although Kim @ IANA might have a 
different opinion and he’s more authoritative).  What I believe matters is that 
there is consensus that additional data is needed.  I’m not sure we’re at that 
point as yet — too many people appear to know The Truth.

Regards,
-drc

Re: fun with TLDs and captive portals was, Redploying most of 127/8 as unicast public

[John Levine]

It appears that Francis Booth via NANOG  said:
>So we know RFC 2606 defined reserved TLDs like .lan and .home so there

Um, this must be a different RFC 2606 than the one the rest of us have read.
It mentions neither .lan nor .home.

>In order to solve the chicken/egg problem of having to know your IPv6
>prefix and the address assigned to your router dynamically for
>nontechnical users to reach their router configuration pages, ...

SLAAC lets hosts find their prefix and router and optionally other
stuff like the DNS servers.  See RFC4862.  This is a thoroughly solved problem.
If your router is a captive portal like at a coffee shop and client devices
need to open a web page to log in, see RFC 8910.

R's,
John

Re: Redploying most of 127/8 as unicast public

[Francis Booth via NANOG]

> On Nov 20, 2021, at 6:35 PM, Matthew Walster  wrote:
> 
> I genuinely believe we're reaching a stalling point for IPv6 service 
> enabling, and it's time to focus energy on running IPv6 only clients -- and 
> to do that, we need to make the IPv6 only experience for residential / soho 
> be as pain-free as possible, no extra knowledge required. 


If I may play devils advocate,

Google’s WiFi pucks did something I thought was interesting that I have not 
seen replicated by others that may or may not be of use to us in this regard. 
By using a local DNS resolver running on the main WiFi puck in the network, 
they handed it out via DHCP for clients to use which helped resolve a local 
webpage that showed devices that were connected to the local network by 
navigating to “on.here” inside a web browser.

That got me thinking, 

So we know RFC 2606 defined reserved TLDs like .lan and .home so there is 
already a known list of .TLDs that we know would be safe to use in local scope, 
and besides the people who are already doing their own thing eg: people running 
PiHole or similar service inside their networks, or those who insist on setting 
their DNS servers static, everybody else should be defaulting to whatever is 
being handed out by their routers' DHCP server so keeping that in mind what if 
we did something like this:

In order to solve the chicken/egg problem of having to know your IPv6 prefix 
and the address assigned to your router dynamically for nontechnical users to 
reach their router configuration pages, the router can run a local DNS resolver 
for the “.lan” TLD by default that it hands out through RDNSS in it’s RAs. 
Since the router is the “first” device in the network, it should always take 
the “router.lan” entry for itself and populate it with its IPv6 address. 
(Obviously proper inbound filtering should prevent external hosts out on the 
Internet from reaching the router configuration page.) Local devices will then 
be able to resolve and reach stuff from within the internal network by 
hostname. Since the router would also be the first device to become aware of 
any IPv6 prefix change from the ISP, it lends itself to loop this prefix update 
into the same processes it would use to update the router’s RA configuration 
back to the clients and to update it’s local DNS entry for “router.lan”. Best 
case scenario the prefix update will happen fast enough that it goes unnoticed 
and clients see minimal disruption.

I feel users may find this method preferable in comparison to the old method of 
“type in 192.168.1.1 in your browser” where those instructions were not always 
100% accurate due to some vendors deciding to use a different variation of 
private range addresses (I’m looking at you 192.168.0.1, and 192.168.100.1). 
Everybody would be able to quickly find their routers regardless of vendor, 
model, firmware version, or ISP.

So (in theory) we have a reliable method of discovering our router 
configuration page without any prior knowledge of our IPv6 prefix, the IPv6 
address assigned to ourselves, or that of the router. We could possibly even 
support dynamic DNS entries for connected devices that used DHCPv6 (Android 
obviously not able to take advantage of due to lack of support) to request 
addresses from the pool. As long as vendors set unique hostnames that don't 
overlap at the factory or attempt to re-use simple hostnames like 
chromecast.lan (sorry, I’m picking on Google a lot here.) where the potential 
for multiple devices to be named the same could occur, I can’t imagine that 
occurring in Residential / SoHo networks all that often but the potential for 
it is cetainly there.

But this solution is by no means perfect, there are various situations I can 
think of where this kind of automation may break down and not work entirely as 
anticipated, eg: devices joining the network with device MAC address 
randomization turned on which I know is a default on certain devices and OSes 
(Android 11 comes to mind), or networks where the administrators do not want to 
allow joined devices to create their own dynamic DNS entries into the zone, but 
I digress, those environments are outside the scope of who this is designed for.

I hope others may take inspiration from this idea and maybe expand upon it or 
even get inspiration to design something that better fits the bill for what 
you’re looking for. Feedback is always welcome.

(Sorry to Matt and Owen who got this message twice. I originally sent this 
reply from my secondary address that is not subscribed on the list and the 
original reply got rejected)

-
Francis Booth
boo...@boothlabs.me

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[William Herrin]

On Tue, Nov 23, 2021 at 5:03 AM Eliot Lear  wrote:
> So what's the road to actually being able to use [240/4]?

1. Move it from "reserved" to "unallocated unicast" (IETF action)
2. Wait 10 years
3. Now that nearly all equipment that didn't treat it as
yet-to-be-allocated unicast has cycled out of use, argue about what to
allocate the addresses to for best effect.


Similar plan for 0/8, 255/8 and 127/8-127.0/16:

1. Move from their existing status to "deprecated former use;
unallocated unicast."
2. Wait 10 years.
3. Now that most equipment that didn't treat it as yet-to-be-allocated
unicast has cycled out of use, argue about what to allocate the
addresses to.


Bottom line though is that the IETF has to act before anyone else
reasonably can.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Eliot Lear]

Greg

Thanks for posting the links.  Our old draft seems to have largely had 
its intended effect without ever having been issued as an RFC 
(moohaha).  Most implementations don't hardcode 240/4 into a bogon 
filter.  We had at the time left open what next steps should be.


So what's the road to actually being able to use this space?  It 
depends.  If you want to use it for your interior, and return 
routability beyond your AS and external in-addr service is NOT 
important, all that stops you today is whatever set of issues you find 
in your own back yard.


If you want to allocate space to customers or need in-addr/return 
routability, obviously that's More Work that should not be 
underestimated.  240/4 appears in a number of bogon filters, not all of 
which are controlled by people tracking operator lists or the IETF.


And that complicates matters in terms of whether the space should be 
moved to a unallocated or treated like 10/8.  At least the latter seems 
to match the testing that has thus far been performed.


Eliot


On 23.11.21 02:01, Greg Skinner via NANOG wrote:



On Nov 21, 2021, at 1:20 PM, William Herrin  wrote:

On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear ofcourseimright.com > wrote:

In 2008, Vince Fuller, Dave Meyer, and I put together
draft-fuller-240space, and we presented it to the IETF. There were
definitely people who thought we should just try to get to v6, but what
really stopped us was a point that Dave Thaler made: unintended impact
on non-participating devices, and in particular CPE/consumer firewall
gear, and at the time there were  serious concerns about some endpoint
systems as well.  Back then it might have been possible to use the space
as part of an SP interior, but no SP demonstrated any interest at the
time, because it would have amounted to an additional transition.


Hi Eliot,

I wasn't in the working group so I'll take your word for it. Something
rather different happened later when folks on NANOG discovered that
the IETF had considered and abandoned the idea. Opinion coalesced into
two core groups:

Group 1: Shut up and use IPv6. We don't want the IETF or vendors
distracted from that effort with improvements to IPv4. Mumble mumble
titanic deck chairs harrumph.

Group 2: Why is the IETF being so myopic? We're likely to need more
IPv4 addresses, 240/4 is untouched, and this sort of change has a long
lead time. Mumble mumble heads up tailpipes harrumph.


More than a decade later, the "titantic" is shockingly still afloat
and it would be strikingly useful if there were a mostly working /4 of
IP addresses we could argue about how best to employ.

Regards,
Bill Herrin


--
William Herrin
bill at herrin.us 
https://bill.herrin.us/



I agree, generally speaking.  IMO, it’s unfortunate that these 
addresses are being held in “limbo” while these debates go on.  I’m 
not complaining about the debates per se, but the longer we go without 
resolution, these addresses can’t be put to any (documented) use.


There’s background information available that might be helpful to 
those who haven’t yet seen it:


https://datatracker.ietf.org/doc/slides-70-intarea-4/ (links to the 
draft-fuller-240space slides from IETF 70)
https://datatracker.ietf.org/doc/minutes-70-intarea/ (IETF 70 INTAREA 
meeting minutes)
https://mailman.nanog.org/pipermail/nanog/2007-October/thread.html (NANOG 
October 2007 mail archives, containing links to the “240/4” thread)

https://puck.nether.net/pipermail/240-e/ (the 240-e archives)
https://mailarchive.ietf.org/arch/browse/int-area/ (IETF INTAREA 
archives, containing comments on the 240space draft and related 
issues, roughly in the same time frame as in the previous links)


—gregbo



OpenPGP_signature
Description: OpenPGP digital signature

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Greg Skinner via NANOG]

> On Nov 21, 2021, at 1:20 PM, William Herrin  wrote:
> 
> On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear  
> wrote:
>> In 2008, Vince Fuller, Dave Meyer, and I put together
>> draft-fuller-240space, and we presented it to the IETF. There were
>> definitely people who thought we should just try to get to v6, but what
>> really stopped us was a point that Dave Thaler made: unintended impact
>> on non-participating devices, and in particular CPE/consumer firewall
>> gear, and at the time there were  serious concerns about some endpoint
>> systems as well.  Back then it might have been possible to use the space
>> as part of an SP interior, but no SP demonstrated any interest at the
>> time, because it would have amounted to an additional transition.
> 
> Hi Eliot,
> 
> I wasn't in the working group so I'll take your word for it. Something
> rather different happened later when folks on NANOG discovered that
> the IETF had considered and abandoned the idea. Opinion coalesced into
> two core groups:
> 
> Group 1: Shut up and use IPv6. We don't want the IETF or vendors
> distracted from that effort with improvements to IPv4. Mumble mumble
> titanic deck chairs harrumph.
> 
> Group 2: Why is the IETF being so myopic? We're likely to need more
> IPv4 addresses, 240/4 is untouched, and this sort of change has a long
> lead time. Mumble mumble heads up tailpipes harrumph.
> 
> 
> More than a decade later, the "titantic" is shockingly still afloat
> and it would be strikingly useful if there were a mostly working /4 of
> IP addresses we could argue about how best to employ.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin
> bill at herrin.us
> https://bill.herrin.us/
> 

I agree, generally speaking.  IMO, it’s unfortunate that these addresses are 
being held in “limbo” while these debates go on.  I’m not complaining about the 
debates per se, but the longer we go without resolution, these addresses can’t 
be put to any (documented) use.

There’s background information available that might be helpful to those who 
haven’t yet seen it:

https://datatracker.ietf.org/doc/slides-70-intarea-4/ 
 (links to the 
draft-fuller-240space slides from IETF 70)
https://datatracker.ietf.org/doc/minutes-70-intarea/ 
 (IETF 70 INTAREA meeting 
minutes)
https://mailman.nanog.org/pipermail/nanog/2007-October/thread.html 
 (NANOG 
October 2007 mail archives, containing links to the “240/4” thread)
https://puck.nether.net/pipermail/240-e/ 
 (the 240-e archives)
https://mailarchive.ietf.org/arch/browse/int-area/ 
 (IETF INTAREA archives, 
containing comments on the 240space draft and related issues, roughly in the 
same time frame as in the previous links)

—gregbo

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 20, 2021, at 21:00 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong wrote:
> 
>> Agreed. But I have every right to express my desires and displeasures with 
>> widespread plans to encourage what I perceive as misuse and that’s exactly 
>> what’s happening here.
>> 
>> My right to attempt to discourage it by opposing proposed standards is 
>> exactly equal to your right to encourage it by promoting them.
> 
> Since your discouragement may take form in preventing some amount of 
> improvement or amelioration to IPv4 users, there is a human cost associated 
> to that.

Since wasted effort may prevent other things I see as advantageous to the 
network and humanity in general from happening, there is a human cost to not 
preventing it.

> Absent the equivalent clear correlation of harm to whatever else you believe 
> those resources are engaged in, I would not say those two behaviors are of 
> equal consequence.

You are entitled to your opinion. I do not happen to share it.

>> I’m really saying what I said. That IMHO, there’s no benefit to the internet 
>> overall if this proposed change is accepted and/or implemented and I see no 
>> benefit to standardizing it. As such, I remain opposed to doing so.
> 
> There is a clear difference of opinion on this, that there stands a very good 
> chance that prompt implementation now may prove to provide significant 
> benefit in the future, should IPv6 continue to lag, which you cannot 
> guarantee it wont.

There stands some chance. It’s not clear how good that chance is. Obviously you 
think it is a higher probability than I do. You also assume that it would be 
widely implemented faster than deployment of IPv6 which is also an assertion of 
which I remain unconvinced.

> Further, there is historical precedent that discouraging re-purposing IPv4 
> addressing is the wrong decision.

Nope… There is historical precedent that you don’t like it. IMHO, we’ve done 
far too many things and put far too much effort into avoiding rather than 
completing IPv6 transition. As such, I think that the historical precedent 
argues that adding to those errors will not accelerate IPv6 transition and is, 
therefore, wasted effort at best and potentially counterproductive.

>> Whether or not the effort that would be wasted implementing it would go to 
>> IPv6 or to some other more useful pursuit is not a concern I factor into my 
>> opinion in this case.
> 
> And I appreciate that, as I consider that reasoning to be specious at best, 
> morally dubious at worst.

At least we agree on something.

>> Again, have not made any such assumption here, either. It’s not relevant. 
>> The only thing I consider relevant is that any resources expended on a 
>> complete waste of time could be better
>> expended elsewhere.
> 
> I dont consider my opinion as to what people's effort should be spent on 
> relevant to whether a particular proposal has merit all of its own.

IMHO, the proposal has no merit and is therefore a waste of time. Clearly you 
disagree. That’s fine.

>>> Which GUA and LL are not, no matter how readily available and easily 
>>> assignable and otherwise equivalent they are in every way but the one. They 
>>> are not loopback designated by standard (and system implementation).
>> And this matters why?
>> 
>> Owen
> 
> So re-purpose 127/8 and if users and developers agree with you, it will 
> become available right about the time IPv6 should have finally managed to 
> obsolete IPv4, no harm no foul. And if it fails at that again, at least we 
> will have 127/8 and cohorts.

Meh, feel free to do whatever you want. In terms of any IETF WG adoption call 
or consensus call, I’ll object as I consider it useless at best and harmful at 
worst.

Nothing you have said provides any indication that there is sufficient merit to 
be worth the time I have wasted on this thread, let alone further effort.

Owen

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 20, 2021, at 20:37 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong wrote:
>> 
>>> On Nov 20, 2021, at 19:11 , Joe Maimon  wrote:
>>> 
>>> 
>>> 
>>> Owen DeLong wrote:
 I guess I don’t see the need/benefit for a dedicated loopback prefix in 
 excess of one address. I’m not necessary inherently opposed to designating 
 one (which would be all that is required for IPv6 to have one, no software 
 updates would be necessary), but I’d need some additional convincing of 
 its utility to support such a notion.
>>> Since the loopback prefix in IPv4 is present and usable on all systems, 
>>> IPv6 parity would require the same, so merely designating a prefix would 
>>> only be the beginning.
>>> 
>>> There may not be a need. But there is clearly some benefit.
>> Which is? You still haven’t answered that question.
> 
> You have right below.
> 
> And if there is indeed no benefit, than there is no reason not to repurpose 
> 127/8 considering that you may use many other ranges in IPv4 for loopback and 
> that you can just use IPv6 for loopback and there you go you have a whole /10.

One doesn’t need a reason for inaction… One needs a reason to act. There is (so 
far) no compelling reason to repurpose 127/8 as far as I can see.

> Its not like it will overnight cause system admin headaches. And they should 
> be running their loopback apps on IPv6 anyways.

You are arguing that just because we can do a thing, we should do a thing. I am 
arguing that unless there’s a compelling reason to change the standard, we 
should leave it as is until it dies a natural death of old age.
(or alternatively until we finally disconnect the life support keeping it 
artificially alive which is a more accurate metaphor for the current state of 
IPv4).

>> Well, technically, fe80::/10 is also present and predictable on every 
>> loopback interface. It does come with the additional baggage of having to 
>> specify a scope id when referencing it, but that’s pretty minor.
>> 
>> 
>> Nope… It’s every bit as deterministic as 127.0.0.0/8.
>> 
>> If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you 
>> try it on something other than linux, it probably doesn’t work.
>> That’s also true of 127.*.*.*.
> 
> So fe80::/10 is the loopback prefix for IPv6

It’s link local. It’s present on loopback. fe80::/10%lo0 (on a linux box) is a 
loopback prefix for IPv6 which is universally deployed.
The scope id becomes important in this context, but other than that, it’s 
identical to the semantics of IPv4.

Owen

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 20, 2021, at 19:47 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong via NANOG wrote:
> 
> (snips for brevity and reply relevancy)
>> 
>> This is a common fallacy… The real concept here isn’t “universal 
>> reachability”, but universal transparent addressing. Policy then decides 
>> about reachability.
>> 
>> Think stateful firewall without NAT.
>> 
>> No, NAT is not a firewall. The stateful inspection that NAT depends on is a 
>> firewall.
>> 
>> You can do all of the exact same things without needing NAT. You just get 
>> additional capabilities without NAT that you didn’t have with NAT due to the 
>> limitations of shared addressing.
>> 
>> You an do stateful inspection and reject unwanted packets without having to 
>> mutilate the packet header in the process.
>> 
>> 
>> Owen
>> 
> 
> You are completely correct in theory.
> 
> However, in IPv4 there is a generally true assumption that there are all 
> these sorts of devices  that will be deployed in a somewhat secure fashion 
> and not by virtue of any particular efforts on the part of their 
> manufactures, because they are rarely deployed without a NAT in front of them 
> simply due to address scarcity, where NAT becomes a feature of network 
> functionality and not of network security.

This is a fallacy which has repeatedly been proven false by numerous security 
researchers. It’s time to educate beyond this silly assertion and recognize 
that NAT is an obfuscation tool, not a security tool.

They are at least as secure behind a non-NAT stateful firewall as they are 
behind NAT.

> The hope that there will be equivalent pervasiveness of a statefull deny-any 
> layer in front of these classes of devices or that they will be 
> deployed|developed with sufficient/equivalent security without that layer is 
> not nearly as re-assuring.

Virtually all home gateways today ship with a stateful default deny-all policy 
for IPv6, so it’s not a hope, it’s current reality.

There is hope that manufacturers will eventually start improving security as 
well, but I agree that depending on that at this stage is rather perilous.

OTOH, it’s also perilous to believe that NAT provides adequate protection for 
their failures in this arena.

> Worse, with the assumption of NAT induced security in place its all too 
> logical to predict and expect that these devices are woefully under-equipped 
> to protect themselves in any way without it.

NAT does not induce security. It induces headaches. It induces difficulties in 
troubleshooting. It induces difficulties in correlating logs and audit trails. 
It induces all manner of things that make it harder to address security 
incidents. It does NOT induce security.

Further, 100% of the alleged or perceived security gains attribute to NAT come 
from stateful inspection, not NAT itself. As such, no, there’s no need for NAT 
to have equivalent security even if you just assume a stateful default deny-all 
in the gateway vs. assuming NAT.

I agree that the idea of producing a home gateway without a stateful default 
deny-any inbound policy should be (and basically is, frankly) as unrealistic as 
producing a home gateway for IPv4 without NAT, but once that’s the case (and 
really, from what I have seen of current market entrants, it is), there’s no 
meaningful difference in the security level between the two options. The 
non-NAT option does provide greater choice and freedom in controlling your 
security and permitting things in, but not significantly more dangerous than 
current port forwarding setups with NAT.

> Best case scenario is that practically all SOHO v6 gateways default 
> configuration is statefull deny-any. In which case all you can hope to get 
> from theoretical E2E is less packet mangling.

That’s already the case from my observations. OpenWRT, Linksys, Netgear, 
D-Link, Belkin, and several others all default this way already.

> (Packet mangling is a good test case for protocols who needlessly commit 
> layering violations by embedding lower layer addressing directly or 
> implicitly into their behavior, so NAT has actually been beneficial in this 
> manner)

If you want to put packet mangling capability into test equipment in SQA 
environments, by all means, feel free, but it has no useful place in the modern 
internet once we move forward from restricted addressing.

> The security conscious are better off deploying these devices with IPv6 
> turned off. Much less chance of them accidentally becoming individually 
> responsible for their own protection due to any network changes that may not 
> take their existence or particularly sensitive and vulnerable state into 
> consideration.

We can agree to disagree here. The security conscious are better off deploying 
these products IPv6-only where they can get proper audit and log correlation 
with transparent addressing and making sure that the upstream router(s) have 
adequate protection configured. That’s at least as good as having a NAT 
upstream, given 

Re: Redploying most of 127/8 as unicast public

[William Herrin]

On Sat, Nov 20, 2021 at 7:16 PM Owen DeLong via NANOG  wrote:
> This is a common fallacy… The real concept here isn’t “universal 
> reachability”, but universal transparent addressing. Policy then decides 
> about reachability.
>
> Think stateful firewall without NAT.
>
> If you want to allow the incoming connection, you simply permit it rather 
> than having to set up some sort of convoluted port forward.
>
> You can allow open access to a hardened host entirely, or you can open 
> specific ports.
>
> What you don’t have to do is carefully map a limited number of external ports 
> to each be forwarded to a particular port on a particular
> internal destination host because you aren’t recycling the one and only 
> public address that all the incoming packets have to first land
> on, each host has its own address that you can simply enable.
>
> So again, how is port forwarding better than this? (it isn’t).

Hi Owen,

This has been hashed and rehashed on this group about a gajillion
times but for the sake of those who are new:

Firewalls are programmed by people. People make mistakes. Lots of
mistakes. 1:1 stateful firewalls and 1:many stateful firewalls (NAT)
behave differently in the face of those mistakes. When 1:1 stateful
firewalls are mistakenly told to pass all traffic they faithfully do
so exposing unhardened hosts directly to the Internet. When 1:many
stateful firewalls (NAT) are mistakenly told to pass all traffic they
can't do so. They don't have enough information to decide which
interior host to send a packet to so they simply break.

One fails as a security perimeter breach. The other fails as a system
down. Pick which security posture you prefer but they're very much not
the same. A knocked over fence versus a lost padlock key and well into
the zombie apocalypse.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[William Herrin]

On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear  wrote:
> In 2008, Vince Fuller, Dave Meyer, and I put together
> draft-fuller-240space, and we presented it to the IETF. There were
> definitely people who thought we should just try to get to v6, but what
> really stopped us was a point that Dave Thaler made: unintended impact
> on non-participating devices, and in particular CPE/consumer firewall
> gear, and at the time there were  serious concerns about some endpoint
> systems as well.  Back then it might have been possible to use the space
> as part of an SP interior, but no SP demonstrated any interest at the
> time, because it would have amounted to an additional transition.

Hi Eliot,

I wasn't in the working group so I'll take your word for it. Something
rather different happened later when folks on NANOG discovered that
the IETF had considered and abandoned the idea. Opinion coalesced into
two core groups:

Group 1: Shut up and use IPv6. We don't want the IETF or vendors
distracted from that effort with improvements to IPv4. Mumble mumble
titanic deck chairs harrumph.

Group 2: Why is the IETF being so myopic? We're likely to need more
IPv4 addresses, 240/4 is untouched, and this sort of change has a long
lead time. Mumble mumble heads up tailpipes harrumph.


More than a decade later, the "titantic" is shockingly still afloat
and it would be strikingly useful if there were a mostly working /4 of
IP addresses we could argue about how best to employ.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 
at 10:47:10PM -0500 Quoting Joe Maimon (jmai...@jmaimon.com):

> layer in front of these classes of devices or that they will be
> deployed|developed with sufficient/equivalent security without that layer is
> not nearly as re-assuring.

The inside/outside paradigm inherent in the reasoning of "NAT is a good,
big part of my firewall" crowd is woefully inadequate to describe and
counter the threats of today. The techniques to get past uni-reachability
(The NATted client can ask the net, but not in reverse) are many and
advanced. Since there is a somewhat inflated belief of the efficiency
of the unroutability paradigm, once inside, the rules tend to be relaxed.

It might very well be so that the resultant protection level will be better
once you realise you can't trust the net to not deliver packets to you. 

Also, I much prefer writing firewall rules where the IP addresses don't
change in-flight. Less to screw up. 
-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
Of course, you UNDERSTAND about the PLAIDS in the SPIN CYCLE --


signature.asc
Description: PGP signature

RE: Class D addresses? was: Redploying most of 127/8 as unicast public

[Richard Irving]

“In the early to mid 90's it was still a crap shoot of whether IP was
going to win (though it was really the only game in town for non-lan)
but by when I started at Cisco in 1998 it was the clear winner with
broadband starting to roll out”



IP was the clear winner since the Clinton-Gore Initiative of 1991, as we called 
it in 1991. (History records this as the  “Gore Bill”, feel free to Google.) [ 
He invented the Internet, you know!  ] at which time we began prototype 
conversion of non-DOD Government agencies to “The IP Paradigm”, till about 
94-95, when the next phase was rollout to K-12 and Public libraries, as well as 
mainstream ISP’s.  This necessitated the birth of the NAP’s. These NAP’s were 
supposed to be -Private- sector, not Public. Many of us “Riding the Bill” left 
Public sector contracting to Private sector to facilitate this transition. 
(Hence the date of my ARIN-POC, actually just POC, ARIN didn’t exist yet) The 
debate in 95 was not “IP or not IP”, it was “Will your NAP be FDDI like the 
MAE’s, ATM, or even the LINX model of a GIGE switch. (Frame was already fading) 
“ While in private sector there may have been some doubt, the IP Juggernaut was 
well underway in Government by almost half a decade, and as they say “That is 
the sound of inevitability, Neo”, at that point.  IP was as “nailed to the 
wall” early to mid 90’s as Tony Li’s resignation was to his bosses door, at 
Cisco, a year or so, later. However, FWIW, the private sector had yet to hear 
the sound of the train. Many brand protocol loyalist fought IP adoption all the 
way until their favorite brand -adopted- it, so I understand your perspective.

FWIW, I miss being able to fit into my “No 53” Tee Shirt. ☹

Matter of fact, many of us missed the foreshadowing of the “woke” generation 
when we got in trouble for painting cross hairs on a backhoe for a NANOG Tee… 
it got “banned” for “possibly inciting violence against backhoe operators” .

:-*



Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: Michael Thomas<mailto:m...@mtcc.com>
Sent: Saturday, November 20, 2021 3:52 PM
To: William Herrin<mailto:b...@herrin.us>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast public


On 11/20/21 12:37 PM, William Herrin wrote:
> On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas  wrote:
>> Was it the politics of ipv6 that
>> this didn't get resolved in the 90's when it was a lot more tractable?
> No, in the '90s we didn't have nearly the basis for looking ahead. We
> might still have invented a new way to use IP addresses that required
> a block that wasn't unicast. It was politics in the 2000's and the
> 2010's, as it is today.

In the early to mid 90's it was still a crap shoot of whether IP was
going to win (though it was really the only game in town for non-lan)
but by when I started at Cisco in 1998 it was the clear winner with
broadband starting to roll out. It was also obvious that v4 address
space was going to run out which of course was the core reason for v6.
So I don't understand why this didn't get done then when it was a *lot*
easier. It sure smacks of politics.

Mike

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Eliot Lear]

Bill,


On 20.11.21 21:37, William Herrin wrote:

On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas  wrote:

Was it the politics of ipv6 that
this didn't get resolved in the 90's when it was a lot more tractable?

No, in the '90s we didn't have nearly the basis for looking ahead. We
might still have invented a new way to use IP addresses that required
a block that wasn't unicast. It was politics in the 2000's and the
2010's, as it is today.


That really isn't what happened.

In 2008, Vince Fuller, Dave Meyer, and I put together 
draft-fuller-240space, and we presented it to the IETF. There were 
definitely people who thought we should just try to get to v6, but what 
really stopped us was a point that Dave Thaler made: unintended impact 
on non-participating devices, and in particular CPE/consumer firewall 
gear, and at the time there were  serious concerns about some endpoint 
systems as well.  Back then it might have been possible to use the space 
as part of an SP interior, but no SP demonstrated any interest at the 
time, because it would have amounted to an additional transition.


Eliot



OpenPGP_signature
Description: OpenPGP digital signature

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Max Harmony via NANOG wrote:

On 21 Nov 2021, at 00.00, Joe Maimon  wrote:

There is a clear difference of opinion on this, that there stands a very good 
chance that prompt implementation now may prove to provide significant benefit 
in the future, should IPv6 continue to lag, which you cannot guarantee it wont.

The reassignment being implemented faster than IPv6 seems like a big assumption.


Suppose you are correct. This time. Even a broken clock can be right 
twice a day.


The only loss for the most part in most of these related proposals is 
the time spent dickering on them and a few extra patches thrown in over 
the next decade.


So just agree already.

127/8 is actually the proposal with the most potential for 
implementation issues as the definition change wends its way into system 
updates. And its easy to see that typical system updates tend to bring 
far greater disruption to system administrators on a regular basis. I 
would not rule out this change in that regard.


And if you are wrong, as history suggests you may very well be?

What is lost by not acting now is possibly far greater.

Joe

Re: Redploying most of 127/8 as unicast public

[Max Harmony via NANOG]

On 21 Nov 2021, at 00.00, Joe Maimon  wrote:
> 
> There is a clear difference of opinion on this, that there stands a very good 
> chance that prompt implementation now may prove to provide significant 
> benefit in the future, should IPv6 continue to lag, which you cannot 
> guarantee it wont.

The reassignment being implemented faster than IPv6 seems like a big assumption.

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Owen DeLong wrote:


Agreed. But I have every right to express my desires and displeasures with 
widespread plans to encourage what I perceive as misuse and that’s exactly 
what’s happening here.

My right to attempt to discourage it by opposing proposed standards is exactly 
equal to your right to encourage it by promoting them.


Since your discouragement may take form in preventing some amount of 
improvement or amelioration to IPv4 users, there is a human cost 
associated to that.


Absent the equivalent clear correlation of harm to whatever else you 
believe those resources are engaged in, I would not say those two 
behaviors are of equal consequence.



I’m really saying what I said. That IMHO, there’s no benefit to the internet 
overall if this proposed change is accepted and/or implemented and I see no 
benefit to standardizing it. As such, I remain opposed to doing so.


There is a clear difference of opinion on this, that there stands a very 
good chance that prompt implementation now may prove to provide 
significant benefit in the future, should IPv6 continue to lag, which 
you cannot guarantee it wont.


Further, there is historical precedent that discouraging re-purposing 
IPv4 addressing is the wrong decision.




Whether or not the effort that would be wasted implementing it would go to IPv6 
or to some other more useful pursuit is not a concern I factor into my opinion 
in this case.


And I appreciate that, as I consider that reasoning to be specious at 
best, morally dubious at worst.



Again, have not made any such assumption here, either. It’s not relevant. The 
only thing I consider relevant is that any resources expended on a complete 
waste of time could be better
expended elsewhere.


I dont consider my opinion as to what people's effort should be spent on 
relevant to whether a particular proposal has merit all of its own.



Which GUA and LL are not, no matter how readily available and easily assignable 
and otherwise equivalent they are in every way but the one. They are not 
loopback designated by standard (and system implementation).

And this matters why?

Owen


So re-purpose 127/8 and if users and developers agree with you, it will 
become available right about the time IPv6 should have finally managed 
to obsolete IPv4, no harm no foul. And if it fails at that again, at 
least we will have 127/8 and cohorts.


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Owen DeLong wrote:



On Nov 20, 2021, at 19:11 , Joe Maimon  wrote:



Owen DeLong wrote:

I guess I don’t see the need/benefit for a dedicated loopback prefix in excess 
of one address. I’m not necessary inherently opposed to designating one (which 
would be all that is required for IPv6 to have one, no software updates would 
be necessary), but I’d need some additional convincing of its utility to 
support such a notion.

Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 
parity would require the same, so merely designating a prefix would only be the 
beginning.

There may not be a need. But there is clearly some benefit.

Which is? You still haven’t answered that question.


You have right below.

And if there is indeed no benefit, than there is no reason not to 
repurpose 127/8 considering that you may use many other ranges in IPv4 
for loopback and that you can just use IPv6 for loopback and there you 
go you have a whole /10.


Its not like it will overnight cause system admin headaches. And they 
should be running their loopback apps on IPv6 anyways.


Well, technically, fe80::/10 is also present and predictable on every loopback 
interface. It does come with the additional baggage of having to specify a 
scope id when referencing it, but that’s pretty minor.


Nope… It’s every bit as deterministic as 127.0.0.0/8.

If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you 
try it on something other than linux, it probably doesn’t work.
That’s also true of 127.*.*.*.


So fe80::/10 is the loopback prefix for IPv6


Joe

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 20, 2021, at 19:11 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong wrote:
>> 
>> I guess I don’t see the need/benefit for a dedicated loopback prefix in 
>> excess of one address. I’m not necessary inherently opposed to designating 
>> one (which would be all that is required for IPv6 to have one, no software 
>> updates would be necessary), but I’d need some additional convincing of its 
>> utility to support such a notion.
> 
> Since the loopback prefix in IPv4 is present and usable on all systems, IPv6 
> parity would require the same, so merely designating a prefix would only be 
> the beginning.
> 
> There may not be a need. But there is clearly some benefit.

Which is? You still haven’t answered that question.

>>> I can understand that sometimes you may explicitly not want to use the 
>>> loopback prefix for loopback applications. In fact many times. However, you 
>>> dont really have much options when it comes to IPv6
>> I have not encountered a device where I could not assign additional prefixes 
>> to a loopback interface in IPv6, so I’m having trouble understanding your 
>> meaning here.
> 
> In IPv6 if you want a loopback prefix you have to pick one yourself or 
> determine which one the system has chosen on its own. Because there is no 
> dedicated loopback prefix other than ::1/128

Well, technically, fe80::/10 is also present and predictable on every loopback 
interface. It does come with the additional baggage of having to specify a 
scope id when referencing it, but that’s pretty minor.

>>> Anyone who wants to assign routable IPv4 to loopback is free to do so and 
>>> there are plenty of IPv4 ranges to choose from.
>>> 
>>> The converse is not true in IPv6.
>> I guess that depends on what you mean by “converse”.
> 
> I mean that in IPv6 you must assign an otherwise non-loopback prefix if you 
> want one.

Again, not really…fe80::/10 is right there waiting for you.

>> If you mean non-routable addresses deployed on the loopback interface, I 
>> think LL works fine for that purpose.
> 
> It works, but it is non deterministic and system dependent.

Nope… It’s every bit as deterministic as 127.0.0.0/8.

If you send packets to fe80::*%lo0 on a linux box, they’ll get there. If you 
try it on something other than linux, it probably doesn’t work.
That’s also true of 127.*.*.*.

>> If you mean routable addresses deployed on the loopback interface, I think 
>> ULA or GUA works fine for that purpose.
> 
> And IPv4 has that too.

Right, so we have parity or better in the case of IPv6.

In IPv4, you have 16.7 Million addresses reserved for this purpose. In IPv6, 
it’s considerably more if you count all of fe80::/10.

(somewhere north of 340,000,000,000,000,000,000,000,000,000,000,000 addresses 
IIRC)

You can also get away with IPv6 loopback behavior on a dual stack system by 
using :::7fxx: as well.

>>> I actually think that IPv6 evangelicals should welcome any all ideas like 
>>> this, especially if they believe it will further degrade the overall state 
>>> of IPv4, because that should only serve as stronger impetus for IPv6 
>>> deployment. That mode of thought has been commonly expressed here and other 
>>> places before.
>> I don’t think the current proposals being discussed will improve or degrade 
>> IPv4. I think they will distract implementors that choose to implement them 
>> from useful work for a while and end in neither benefit nor detriment beyond 
>> the detriment that comes from wasting effort.
> 
> There seems to be some weird mental representation of how standards affect 
> the real world. Standards do not demand or direct or control in any way what 
> individuals do based upon their own assessment of their needs, available 
> resources and resulting benefits.

Maybe, maybe not. They certainly influence some of those choices in a variety 
of ways.

> You are neither responsible or in control of how people choose to expend 
> their implementing resources. Nor should you.

Agreed. But I have every right to express my desires and displeasures with 
widespread plans to encourage what I perceive as misuse and that’s exactly 
what’s happening here.

My right to attempt to discourage it by opposing proposed standards is exactly 
equal to your right to encourage it by promoting them.

> What standards do is increase the potential benefits of conforming to certain 
> behavior.

No, what standards do is encourage people to implement things in compatible 
ways in hopes that doing so is beneficial. A proposed standard that doesn’t 
provide an apparent clear benefit, therefore doesn’t merit adoption.

> So what you are really saying is that standardizing something that others may 
> then choose to recognize as a worthwhile expenditure of their resources is 
> something you would like to prevent on the assumption that those efforts 
> would have otherwise gone into IPv6 advancement.

I’m really saying what I said. That IMHO, there’s no benefit to the internet 
overall if this 

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Owen DeLong via NANOG wrote:

(snips for brevity and reply relevancy)


This is a common fallacy… The real concept here isn’t “universal 
reachability”, but universal transparent addressing. Policy then 
decides about reachability.


Think stateful firewall without NAT.

No, NAT is not a firewall. The stateful inspection that NAT depends on 
is a firewall.


You can do all of the exact same things without needing NAT. You just 
get additional capabilities without NAT that you didn’t have with NAT 
due to the limitations of shared addressing.


You an do stateful inspection and reject unwanted packets without 
having to mutilate the packet header in the process.



Owen



You are completely correct in theory.

However, in IPv4 there is a generally true assumption that there are all 
these sorts of devices  that will be deployed in a somewhat secure 
fashion and not by virtue of any particular efforts on the part of their 
manufactures, because they are rarely deployed without a NAT in front of 
them simply due to address scarcity, where NAT becomes a feature of 
network functionality and not of network security.


The hope that there will be equivalent pervasiveness of a statefull 
deny-any layer in front of these classes of devices or that they will be 
deployed|developed with sufficient/equivalent security without that 
layer is not nearly as re-assuring.


Worse, with the assumption of NAT induced security in place its all too 
logical to predict and expect that these devices are woefully 
under-equipped to protect themselves in any way without it.


Best case scenario is that practically all SOHO v6 gateways default 
configuration is statefull deny-any. In which case all you can hope to 
get from theoretical E2E is less packet mangling.


(Packet mangling is a good test case for protocols who needlessly commit 
layering violations by embedding lower layer addressing directly or 
implicitly into their behavior, so NAT has actually been beneficial in 
this manner)


The security conscious are better off deploying these devices with IPv6 
turned off. Much less chance of them accidentally becoming individually 
responsible for their own protection due to any network changes that may 
not take their existence or particularly sensitive and vulnerable state 
into consideration.


Further, security track records as they are suggest that security will 
never become the prime focus or even more than an afterthought for the 
producers of these classes of devices.


We can all wish that were not the case but it would be naive to assume 
otherwise.


Joe

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 20, 2021, at 15:35 , Matthew Walster  wrote:
> 
> 
> 
> On Sat, 20 Nov 2021 at 22:35, Owen DeLong  <mailto:o...@delong.com>> wrote:
>> On Nov 20, 2021, at 03:16 , Matthew Walster > <mailto:matt...@walster.org>> wrote:
>> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, > <mailto:mansa...@besserwisser.org>> wrote:
>> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 
>> 2021 at 10:26:33AM +0900 Quoting Masataka Ohta 
>> (mo...@necom830.hpcl.titech.ac.jp <mailto:mo...@necom830.hpcl.titech.ac.jp>):
>> 
>> > > We cope,
>> > > because a lot of technical debt is amassed in corporate and ISP /
>> > > access provider networks that won't change.
>> > 
>> > Sounds like abstract nonsense.
>> 
>> No, it is the real reason that we still have v4 around.
>> 
>> The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6 is 
>> relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some 
>> examples:
>> 
>> ***
>> 
>> 1. Your power goes out. When it comes back up, your internet connection is 
>> down. You want to log in to the router... Except you can't. You don't know 
>> the address, and you won't have one until your ISP gives you one via DHCP 
>> (or similar).
> 
> This is contrived. It only happens if you have ignored all reasonable 
> possibility to address this situation in advance.
> 
> Yup. Though this isn't contrived, this is the exact situation I'm having with 
> my ISP at the moment, whose CPE crash-reboots every couple of days and gets a 
> new IPv6 prefix every time... Except when the power goes out (again, 
> annoyingly regularly -- I have had more power outages in 15 months of living 
> here than the last 37 years of my life) and it takes up to 10 minutes for the 
> street to get connectivity again. 

The problem is not contrived…The supposed lack of solutions is contrived.

>> Sure, you could maybe provide the link-local address on the bottom of the 
>> router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd <>] 
>> right (and you might even need interface scoping!) is boring to cause user 
>> frustration when an ISP tech support tries to help, and having the provided 
>> CPE using fe80::1 is probably a recipe for disaster.
>> 
>> Likewise, having an mdns broadcast (h, I know) for "gateway" or "router" 
>> is definitely not something standardised.
> 
> Nor, frankly, should it be, but you are ignoring a number of other possible 
> mitigations:
> 
> 1.Assign an additional “easy” LL address to the device in its 
> configuration. (e.g. fe80::1). Do you think the average user
>   would buy unable to correctly type fe80::1?
> 
> It would be http://[fe80::1] actually, and I presume you need to use 
> interface scoping? I actually don't know that answer...

Yes, interface scoping is required for any LL address on any system with more 
than one interface. Since any system
where this would be useful has at least one external facing interface and one 
loopback interface, that would make it
essentially universally required. As long as your not on Windows, that’s not 
too bad.

> 2.Assign a ULA prefix to the interface (not my preference, but it can 
> work).
> 
> 3.Us a static GUA assignment (more complicated, but not impossible).
> 
> 4.Use a non-standardized MDNS name — Who cares that it isn’t 
> standardized, you just have to remember what you
>   named each of your routers. Brady, Brother, and Dymo all make products 
> to aid in this endeavor.
> 
> The only reason this situation doesn’t exist in IPv4 is because we lack 
> unique addresses for LANs in IPv4.
> In reality, if this were truly an issue, the simple solution would be to 
> predesignate fd00:: as a “household”
> prefix and give every household fd00:: as a prefix in addition to whatever 
> other prefixes may or may not be
> assigned. I don’t see this as desirable, but if you wanted to replicate the 
> problems of IPv4 in this regard, that
> would be one mostly harmless way to do it.
> 
> Indeed, that's what I'm proposing. As /etc/gai.conf (or the equivalent in 
> Windows) would prefer the non-ULA space for addressing, once a connection is 
> up, it would just work with that new prefix, but it would continue to work 
> locally for that non-U ULA.

Absolutely nothing prevents you from doing this today and it is, IIRC, already 
in some of the HOMENET RFCs.

>> 2. Your IPv6 prefix changes. With some ISPs, it can change every time your 
>> router reboots, and if you're with my ISP, it crash-reboots about once a 
>> week! If

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

Please make sure there’s video we can all watch when you try to take DoD’s IP 
addresses
by force.

ROFLMAO

Owen


> On Nov 20, 2021, at 11:20 , Gaurav Kansal  wrote:
> 
> 
> 
>> On 18-Nov-2021, at 09:10, Jerry Cloe > <mailto:je...@jtcloe.net>> wrote:
>> 
>>  
>>  
>> Subject: Redploying most of 127/8 as unicast public
>> To: nanog mailto:nanog@nanog.org>>; 
>> This seems like a really bad idea to me; am I really the only one who 
>> noticed?
>> 
>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html 
>> <https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html>
>>  
>> I can think of about a dozen /8's that would be better to use. (Hint, they 
>> all have DOD in the name.) They haven't been in routing tables for decades 
>> and there wouldn't be hardly any technical issues (like there would be with 
>> 127/8). The only drawback is I've seen a lot of organizations treat them 
>> like rfc1918 space.
>>  
> This seems to be much better idea then 127/8 or 240/8 
>  <https://amritmahotsav.nic.in/>

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 20, 2021, at 13:15 , Matthew Walster  wrote:
> 
> 
> 
> On Sat, 20 Nov 2021 at 13:47, Måns Nilsson  <mailto:mansa...@besserwisser.org>> wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 
> 2021 at 11:16:59AM + Quoting Matthew Walster (matt...@walster.org 
> <mailto:matt...@walster.org>):
> > 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
> > to each machine having a global address. 
> 
> This is the problem in a nutshell. After 27 years of destroying the
> E2E model on the internet, people do not anymore understand how IP
> (regardless of version) was supposed to work; any node to any node.
> 
> Why should we burden ourselves with this cumbersome and painful, useless
> layer of abstraction that is "port forwarding", when the choice of
> universal reachability is around the corner?
> 
> Because it's a REALLY bad idea to have unmanaged devices reachable from the 
> open internet. Dial-out, not dial-in. You need a firewall. You need a way of 
> punching holes in that firewall for services you explicitly allow, be that 
> manually through an interface, or temporarily via an automated system like 
> upnp/nat-pmp.

This is a common fallacy… The real concept here isn’t “universal reachability”, 
but universal transparent addressing. Policy then decides about reachability.

Think stateful firewall without NAT.

If you want to allow the incoming connection, you simply permit it rather than 
having to set up some sort of convoluted port forward.

You can allow open access to a hardened host entirely, or you can open specific 
ports.

What you don’t have to do is carefully map a limited number of external ports 
to each be forwarded to a particular port on a particular
internal destination host because you aren’t recycling the one and only public 
address that all the incoming packets have to first land
on, each host has its own address that you can simply enable.

So again, how is port forwarding better than this? (it isn’t).
 
> If people can set a port forward up, they can click "allow" in a
> routing-based firewall interface. Only it is better, because one can
> have several parallel services using well-known ports. Sometimes (most
> of the time) the protocol spec has no option to change port either,
> making port forwarding futile anyway. (the let's have a TXT record bunch
> at it again, purposefully ignoring SRV since its inception.)
> 
> It's not always people. Lots of games, lots of telephony things, services 
> like Syncthing... They all open firewall holes (yes, NAT is a firewall) to 
> allow inbound connections for specific conditions, like "this protocol and 
> port combination".

No, NAT is not a firewall. The stateful inspection that NAT depends on is a 
firewall.

You can do all of the exact same things without needing NAT. You just get 
additional capabilities without NAT that you didn’t have with NAT due to the 
limitations of shared addressing.
 
> I guess juggling our pains differently is what we are doing here. What
> is unthinkable to one is quite OK to someone else.
> 
> Indeed.

Why juggle pains when you can (mostly) relieve them.

There’s no need for the UI to open a port in IPv6 direct addressing to be any 
more complex (or really even any different) from the UI to set up a port 
forward in IPv4 with NAT. In fact, it’s simpler because you don’t need to 
configure external to internal port mapping, you can simply permit traffic to 
host X port Y.
 
> (But I am right)
> 
> You are not. I'm glad my internet connected light bulbs are controlled by the 
> Australian firm that manufactures them and the American firm that has a 
> surveillance device in my kitchen listening for the immortal words "turn on 
> the living room lights", rather than Billy* from Doncaster who's looking for 
> something funny to do after losing at CS:GO again and happens to have found a 
> list of IP addresses of known vulnerable devices accessible from the internet.

Yes, well, that’s still just as possible with direct addressing as it is with 
NAT.

You an do stateful inspection and reject unwanted packets without having to 
mutilate the packet header in the process.

So to that extent, he is actually right, but you’re applying an emotional 
reaction to a poorly chosen term and it’s overriding actual logic.

Owen

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Owen DeLong wrote:


I guess I don’t see the need/benefit for a dedicated loopback prefix in excess 
of one address. I’m not necessary inherently opposed to designating one (which 
would be all that is required for IPv6 to have one, no software updates would 
be necessary), but I’d need some additional convincing of its utility to 
support such a notion.


Since the loopback prefix in IPv4 is present and usable on all systems, 
IPv6 parity would require the same, so merely designating a prefix would 
only be the beginning.


There may not be a need. But there is clearly some benefit.


I can understand that sometimes you may explicitly not want to use the loopback 
prefix for loopback applications. In fact many times. However, you dont really 
have much options when it comes to IPv6

I have not encountered a device where I could not assign additional prefixes to 
a loopback interface in IPv6, so I’m having trouble understanding your meaning 
here.


In IPv6 if you want a loopback prefix you have to pick one yourself or 
determine which one the system has chosen on its own. Because there is 
no dedicated loopback prefix other than ::1/128





Anyone who wants to assign routable IPv4 to loopback is free to do so and there 
are plenty of IPv4 ranges to choose from.

The converse is not true in IPv6.

I guess that depends on what you mean by “converse”.


I mean that in IPv6 you must assign an otherwise non-loopback prefix if 
you want one.



If you mean non-routable addresses deployed on the loopback interface, I think 
LL works fine for that purpose.


It works, but it is non deterministic and system dependent.

If you mean routable addresses deployed on the loopback interface, I think ULA 
or GUA works fine for that purpose.


And IPv4 has that too.



I actually think that IPv6 evangelicals should welcome any all ideas like this, 
especially if they believe it will further degrade the overall state of IPv4, 
because that should only serve as stronger impetus for IPv6 deployment. That 
mode of thought has been commonly expressed here and other places before.

I don’t think the current proposals being discussed will improve or degrade 
IPv4. I think they will distract implementors that choose to implement them 
from useful work for a while and end in neither benefit nor detriment beyond 
the detriment that comes from wasting effort.


There seems to be some weird mental representation of how standards 
affect the real world. Standards do not demand or direct or control in 
any way what individuals do based upon their own assessment of their 
needs, available resources and resulting benefits.


You are neither responsible or in control of how people choose to expend 
their implementing resources. Nor should you.


What standards do is increase the potential benefits of conforming to 
certain behavior.


So what you are really saying is that standardizing something that 
others may then choose to recognize as a worthwhile expenditure of their 
resources is something you would like to prevent on the assumption that 
those efforts would have otherwise gone into IPv6 advancement.


You dont have the immediate moral high ground on that one.

You dont have the long term moral high ground on that one because such 
thinking isnt new and we know its wishful at best.


You dont have the logical high ground on that one because you are 
assuming facts not in evidence, namely that


- Resources are being feverishly expended deploying IPv6 (as if)

- Those same resources will be the ones redirected to implement ideas 
such as these


- That those efforts are in anyways comparable in scope to work being 
done on IPv6 (which is supposed to be done already)


- That any such diversion of activity will actually have any real world 
affect on the state of IPv6




If I thought it would significantly degrade IPv4, I might be all for it, but I 
doubt it would even be that useful.

Owen



Reclaiming 127/8 while assigning a /64 for loopback in IPv6 would create 
a clear (but narrow) case where IPv6 would be superior to IPv4, 
irrelevant of overall network state.


Objectors to the proposal based upon their real world use of far larger 
than v4 /16 for loopback applications could implement on IPv6 with even 
more space, and in the exact same addressing context.


Which GUA and LL are not, no matter how readily available and easily 
assignable and otherwise equivalent they are in every way but the one. 
They are not loopback designated by standard (and system implementation).


Joe

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[james.cut...@consultant.com]

On Nov 20, 2021, at 3:50 PM, Michael Thomas  wrote:
> 
> In the early to mid 90's it was still a crap shoot of whether IP was going to 
> win (though it was really the only game in town for non-lan) but by when I 
> started at Cisco in 1998 it was the clear winner with broadband starting to 
> roll out. It was also obvious that v4 address space was going to run out 
> which of course was the core reason for v6. So I don't understand why this 
> didn't get done then when it was a *lot* easier. It sure smacks of politics.
> 
> Mike

In the in the 90s and into early 21st century Hesitancy toward IPv6 was partly 
technical, partly political, but mostly, Middle Management Myopia™. The 
rallying cry was, “Not on my cost center until I have a contract.” 
Subsequently, $DAYJOB company would/could not demonstrate IPv6 capability.

My $DAYJOB company no longer exists.

How many other companies will cease to exist as the world passes by them?

Re: Redploying most of 127/8 as unicast public

[Matthew Walster]

On Sat, 20 Nov 2021 at 22:35, Owen DeLong  wrote:

> On Nov 20, 2021, at 03:16 , Matthew Walster  wrote:
> On Sat, 20 Nov 2021, 09:21 Måns Nilsson, 
> wrote:
>
>> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov
>> 20, 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (
>> mo...@necom830.hpcl.titech.ac.jp):
>>
>> > > We cope,
>> > > because a lot of technical debt is amassed in corporate and ISP /
>> > > access provider networks that won't change.
>> >
>> > Sounds like abstract nonsense.
>>
>> No, it is the real reason that we still have v4 around.
>>
>
> The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6
> is relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some
> examples:
>
> ***
>
> 1. Your power goes out. When it comes back up, your internet connection is
> down. You want to log in to the router... Except you can't. You don't know
> the address, and you won't have one until your ISP gives you one via DHCP
> (or similar).
>
>
> This is contrived. It only happens if you have ignored all reasonable
> possibility to address this situation in advance.
>

Yup. Though this isn't contrived, this is the exact situation I'm having
with my ISP at the moment, whose CPE crash-reboots every couple of days and
gets a new IPv6 prefix every time... Except when the power goes out (again,
annoyingly regularly -- I have had more power outages in 15 months of
living here than the last 37 years of my life) and it takes up to 10
minutes for the street to get connectivity again.

> Sure, you could maybe provide the link-local address on the bottom of the
> router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd]
> right (and you might even need interface scoping!) is boring to cause user
> frustration when an ISP tech support tries to help, and having the provided
> CPE using fe80::1 is probably a recipe for disaster.
>
>
> Likewise, having an mdns broadcast (h, I know) for "gateway" or
> "router" is definitely not something standardised.
>
>
> Nor, frankly, should it be, but you are ignoring a number of other
> possible mitigations:
>
> 1. Assign an additional “easy” LL address to the device in its
> configuration. (e.g. fe80::1). Do you think the average user
> would buy unable to correctly type fe80::1?
>

It would be http://[fe80::1] actually, and I presume you need to use
interface scoping? I actually don't know that answer...



> 2. Assign a ULA prefix to the interface (not my preference, but it can
> work).
>
> 3. Us a static GUA assignment (more complicated, but not impossible).
>
> 4. Use a non-standardized MDNS name — Who cares that it isn’t
> standardized, you just have to remember what you
> named each of your routers. Brady, Brother, and Dymo all make products to
> aid in this endeavor.
>
> The only reason this situation doesn’t exist in IPv4 is because we lack
> unique addresses for LANs in IPv4.
> In reality, if this were truly an issue, the simple solution would be to
> predesignate fd00:: as a “household”
> prefix and give every household fd00:: as a prefix in addition to whatever
> other prefixes may or may not be
> assigned. I don’t see this as desirable, but if you wanted to replicate
> the problems of IPv4 in this regard, that
> would be one mostly harmless way to do it.
>

Indeed, that's what I'm proposing. As /etc/gai.conf (or the equivalent in
Windows) would prefer the non-ULA space for addressing, once a connection
is up, it would just work with that new prefix, but it would continue to
work locally for that non-U ULA.

> 2. Your IPv6 prefix changes. With some ISPs, it can change every time your
> router reboots, and if you're with my ISP, it crash-reboots about once a
> week! If your CPE isn't providing your WiFi (range extender, mesh, nerd
> etc) then the old prefix is still valid for a while. Yes, there's an RFC to
> deal with this, but realistically it's not out there today.
>
> Also, any local services are going to break if they're on static
> addresses... I'm not just talking enterprise AD servers etc, it's also CCTV
> cameras, raspberry pis, NAS units etc. DHCP registration of addresses in
> DNS exists, yes, but it's just not used by most of these devices.
>
> This could easily be fixed by having a well-known (and short/memorable!)
> /48 set aside that would have NAT66 (1:1, not port overload) applied at the
> router to the delegated prefix received from the ISP, but I'll be shouted
> down to hell for even mentioning that idea.
>
>
> There are mitigations for this as well. The situation is not any better in
> IPv4 than it is with ULA IPv6. The difference is that with I

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Matthew Walster]

On Sat, 20 Nov 2021 at 22:14, Måns Nilsson 
wrote:

> Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast
> public Date: Sat, Nov 20, 2021 at 11:51:24AM -0800 Quoting William Herrin (
> b...@herrin.us):
> All the heavy lifting in video production via IP is done over
> multicast. Mostly, it is internal to one organisation, and the 239/8
> (RFC2365) block is being used, but routing multi-gbit RTP flows over
> multicast is a thing where I work.
>

239/8 can essentially be looked at as RFC1918 space for multicast. Possibly
time to consider using SSM and the 232/8 block? I hear they have multicast
in IPv6 now. \s

Anyway, AFAICT the 224/4 proposal is actually the 225/8-231/8 proposal,
leaving 224/8 out from that block of otherwise 224/5 (as 232/8-239/8 are
not covered in the proposal).

M

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 20, 2021, at 03:16 , Matthew Walster  wrote:
> 
> 
> 
> On Sat, 20 Nov 2021, 09:21 Måns Nilsson,  <mailto:mansa...@besserwisser.org>> wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 
> 2021 at 10:26:33AM +0900 Quoting Masataka Ohta 
> (mo...@necom830.hpcl.titech.ac.jp <mailto:mo...@necom830.hpcl.titech.ac.jp>):
> 
> > > We cope,
> > > because a lot of technical debt is amassed in corporate and ISP /
> > > access provider networks that won't change.
> > 
> > Sounds like abstract nonsense.
> 
> No, it is the real reason that we still have v4 around.
> 
> The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6 is 
> relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some 
> examples:
> 
> ***
> 
> 1. Your power goes out. When it comes back up, your internet connection is 
> down. You want to log in to the router... Except you can't. You don't know 
> the address, and you won't have one until your ISP gives you one via DHCP (or 
> similar).

This is contrived. It only happens if you have ignored all reasonable 
possibility to address this situation in advance.

> Sure, you could maybe provide the link-local address on the bottom of the 
> router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd] right 
> (and you might even need interface scoping!) is boring to cause user 
> frustration when an ISP tech support tries to help, and having the provided 
> CPE using fe80::1 is probably a recipe for disaster.
> 
> Likewise, having an mdns broadcast (h, I know) for "gateway" or "router" 
> is definitely not something standardised.

Nor, frankly, should it be, but you are ignoring a number of other possible 
mitigations:

1.  Assign an additional “easy” LL address to the device in its 
configuration. (e.g. fe80::1). Do you think the average user
would buy unable to correctly type fe80::1?

2.  Assign a ULA prefix to the interface (not my preference, but it can 
work).

3.  Us a static GUA assignment (more complicated, but not impossible).

4.  Use a non-standardized MDNS name — Who cares that it isn’t 
standardized, you just have to remember what you
named each of your routers. Brady, Brother, and Dymo all make products 
to aid in this endeavor.

The only reason this situation doesn’t exist in IPv4 is because we lack unique 
addresses for LANs in IPv4.
In reality, if this were truly an issue, the simple solution would be to 
predesignate fd00:: as a “household”
prefix and give every household fd00:: as a prefix in addition to whatever 
other prefixes may or may not be
assigned. I don’t see this as desirable, but if you wanted to replicate the 
problems of IPv4 in this regard, that
would be one mostly harmless way to do it.

> 2. Your IPv6 prefix changes. With some ISPs, it can change every time your 
> router reboots, and if you're with my ISP, it crash-reboots about once a 
> week! If your CPE isn't providing your WiFi (range extender, mesh, nerd etc) 
> then the old prefix is still valid for a while. Yes, there's an RFC to deal 
> with this, but realistically it's not out there today.
> 
> Also, any local services are going to break if they're on static addresses... 
> I'm not just talking enterprise AD servers etc, it's also CCTV cameras, 
> raspberry pis, NAS units etc. DHCP registration of addresses in DNS exists, 
> yes, but it's just not used by most of these devices.
> 
> This could easily be fixed by having a well-known (and short/memorable!) /48 
> set aside that would have NAT66 (1:1, not port overload) applied at the 
> router to the delegated prefix received from the ISP, but I'll be shouted 
> down to hell for even mentioning that idea.

There are mitigations for this as well. The situation is not any better in IPv4 
than it is with ULA IPv6. The difference is that with IPv4, you expect to have 
to use NAPT to break your network in order to talk to the outside world and 
with IPv6, you’re now asking to have your cake and eat it too.

There are implementations of exactly what you say you want readily available, 
but fortunately they are not standardized.

> 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used 
> to each machine having a global address. Sure, on many devices you can add 
> firewall rules to allow traffic in, but it's not like the "port forwarding" 
> concept people have gotten used to. I genuinely have no idea whether 
> upnp/nat-pmp has an IPv6 analogue that "just works" which things like 
> consoles (or apps like syncthing) can take advantage of.

Yes, “permit X in” is so much more complicated than “translate Y to X and map Z 
to A and…”

Oh, wait, no it isn’t… People will get 

Re: Redploying most of 127/8 as unicast public

[Gaurav Kansal]

> On 18-Nov-2021, at 09:10, Jerry Cloe  wrote:
> 
>  
>  
> Subject: Redploying most of 127/8 as unicast public
> To: nanog mailto:nanog@nanog.org>>; 
> This seems like a really bad idea to me; am I really the only one who noticed?
> 
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html 
> <https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html>
>  
> I can think of about a dozen /8's that would be better to use. (Hint, they 
> all have DOD in the name.) They haven't been in routing tables for decades 
> and there wouldn't be hardly any technical issues (like there would be with 
> 127/8). The only drawback is I've seen a lot of organizations treat them like 
> rfc1918 space.
>  
This seems to be much better idea then 127/8 or 240/8

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast public 
Date: Sat, Nov 20, 2021 at 11:51:24AM -0800 Quoting William Herrin 
(b...@herrin.us):
 
> Multicast is not the same as broadcast and yes, it's a thing. Mainly
> it's a thing confined to the local broadcast domain but in that scope
> it's quite widely used. 

All the heavy lifting in video production via IP is done over
multicast. Mostly, it is internal to one organisation, and the 239/8
(RFC2365) block is being used, but routing multi-gbit RTP flows over
multicast is a thing where I work.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
YOU!!  Give me the CUTEST, PINKEST, most charming little VICTORIAN
DOLLHOUSE you can find!!  An make it SNAPPY!!


signature.asc
Description: PGP signature

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 
at 09:15:24PM + Quoting Matthew Walster (matt...@walster.org):

> > Why should we burden ourselves with this cumbersome and painful, useless
> > layer of abstraction that is "port forwarding", when the choice of
> > universal reachability is around the corner?
> 
> Because it's a REALLY bad idea to have unmanaged devices reachable from the
> open internet. Dial-out, not dial-in. You need a firewall. You need a way
> of punching holes in that firewall for services you explicitly allow, be
> that manually through an interface, or temporarily via an automated system
> like upnp/nat-pmp.
 
It's like you did not read the next part. 
 
> > If people can set a port forward up, they can click "allow" in a
> > routing-based firewall interface. Only it is better, because one can
> > have several parallel services using well-known ports. Sometimes (most
> > of the time) the protocol spec has no option to change port either,
> > making port forwarding futile anyway. (the let's have a TXT record bunch
> > at it again, purposefully ignoring SRV since its inception.)
> >
> 
> It's not always people. Lots of games, lots of telephony things, services
> like Syncthing... They all open firewall holes (yes, NAT is a firewall) to
> allow inbound connections for specific conditions, like "this protocol and
> port combination".
 
You obviously read it. Now I'm confused. 
 
> You are not. I'm glad my internet connected light bulbs are controlled by
> the Australian firm that manufactures them and the American firm that has a
> surveillance device in my kitchen listening for the immortal words "turn on
> the living room lights", rather than Billy* from Doncaster who's looking
> for something funny to do after losing at CS:GO again and happens to have
> found a list of IP addresses of known vulnerable devices accessible from
> the internet.

( I'd rather not have my lighting in the cloud. But I'm strange like that. )

Routing and allowing traffic are choices. Only that people with unusable
non-unique addresses don't get to make those choices.  One can probably
find quantitative research stating that letting people handle their
IT security makes for less secure systems, and from that standpoint
argue that they don't deserve the choice.  To me, that is elitist and
condescending (And I oughta know condescending, I'm quite good at it.) and
I think we could do better.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
I want another RE-WRITE on my CEASAR SALAD!!


signature.asc
Description: PGP signature

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 19, 2021, at 10:50 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong wrote:
>> 
>>> LLA and ULA and whatever random prefix you may wish to use for loopback, 
>>> whether in IPv6 or even IPv4 have none of these qualities.
>> And if we implement the proposal at hand, which as near as I can tell you 
>> are supporting, that changes.
>> 
>> Having trouble following your desired outcome here. It seems as if you both 
>> want 127.0.0.0/8 to retain it’s unique properties
>> as deterministically loopback only and also want the benefits of repurposing 
>> it as GUA.
>> 
>> Have cake, Eat cake, please to pick only one.
> 
> Let me clear that up then.
> 
> I support serious consideration of the idea. My desired outcome is to see 
> ideas like these either adopted or not but based solely on their own merits 
> and especially in their own protocol context. And that folk who have studied 
> the issue and invested their efforts be taken seriously and not be met with 
> undeserved and might I add, unkind, scorn.
> 
> (I havent studied the issue or invested the effort, so you may continue to 
> direct your scorn this way)
> 
> Its well past time to stop behaving as if we are a bunch of teenagers on a 
> private BBS.
> 
> I like the loopback prefix feature of IPv4.
> 
> I can easily concede that its too large, especially in this day and age. And 
> that there is a good chance that significant benefit can come from addressing 
> that before IPv4 becomes obsolete.
> 
> I question the lack of dedicated loopback feature in IPv6 and I acknowledge 
> that yes, you can accomplish the same with non loopback prefixes by 
> essentially assigning them to loopback, but point out that that does not make 
> them the same thing.

I guess I don’t see the need/benefit for a dedicated loopback prefix in excess 
of one address. I’m not necessary inherently opposed to designating one (which 
would be all that is required for IPv6 to have one, no software updates would 
be necessary), but I’d need some additional convincing of its utility to 
support such a notion.
> 
> I can understand that sometimes you may explicitly not want to use the 
> loopback prefix for loopback applications. In fact many times. However, you 
> dont really have much options when it comes to IPv6

I have not encountered a device where I could not assign additional prefixes to 
a loopback interface in IPv6, so I’m having trouble understanding your meaning 
here.

> And I discuss IPv6 loopback simply because of the pushback directed in a 
> non-meritorious fashion from folk who apparently believe simultaneously that 
> IPv6 is superior in every way to IPv4 and that any improvements|changes to 
> IPv4 somehow endanger IPv6 imminent dominance.

I have little concern (if any) of the latter. I believe that IPv6 is mostly 
equivalent to IPv4 in virtually every way and vastly superior in exactly one 
way… It has enough addresses. (and in all the ways that result from that, i.e. 
potential to restore end to end addressing, elimination of NAPT, etc.). I think 
that IPv6 also offers some features not available in IPv4, the benefits of 
which we haven’t fully explored or realized (MIP6, DHCP-PD, improved zeroconf, 
RD, etc.). Certainly the IPSEC implementation in IPv6 is quite a bit cleaner 
than it’s back-ported counterpart on IPv4 which has become such a nightmare in 
most implementations that the vast majority of VPNs have migrated to some 
cockamamy HTTPS “SSL VPN” thing.

  having a prefix
 dedicated to that purpose globally vs. allowing each site that cares to 
 choose their own doesn’t seem like the best
 tradeoff.
 
 Owen
 
>>> But this is how it is to be done in IPv6, so lets get some lack-of-feature 
>>> parity going with IPv4.
>> I’m all for IPv6 having better implementations than IPv4 rather than mere 
>> feature parity.
> 
> 
> Actually I am (somewhat facetiously) suggesting that IPv4 have non-feature 
> parity with IPv6 by taking away its loopback prefix.

Both have a loopback prefix. IPv4: 127.0.0.0/8 and IPv6: ::1/128

Admittedly, there are a lot more addresses available in the IPv4 loopback 
prefix, but again, I view that as being mostly waste as a result of historical 
ignorance at the time a decision was being made.

>> IMHO, having additional loopbacks be assigned from either LLA or ULA space 
>> (or even GUA, really)
>> where that is needed is a superior choice vs. 127.0.0.0/8.
> 
> Anyone who wants to assign routable IPv4 to loopback is free to do so and 
> there are plenty of IPv4 ranges to choose from.
> 
> The converse is not true in IPv6.

I guess that depends on what you mean by “converse”.
If you mean non-routable addresses deployed on the loopback interface, I think 
LL works fine for that purpose.
If you mean routable addresses deployed on the loopback interface, I think ULA 
or GUA works fine for that purpose.
If you mean something else, then I’m still not clear what you’re intent is here.

>> For one thing, the 

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Enno Rey]

Hi,

On Sat, Nov 20, 2021 at 11:01:35AM -0800, Michael Thomas wrote:
> 
> On 11/20/21 10:44 AM, Chris Adams wrote:
> 
> []
> 
> won out using unicast. Even if it has some niche uses, I seriously doubt 
> that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it 
> seems that class D and class E would be a much better target than loopback.

I agree from an efficiency (= ratio of resources used vs. result achieved), but 
this wouldn't work in practice outside isolated environments for the same 
reasons why the 127/8 is not going to work:
https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/

For the sake of the thread it should be noted that both the reception of and 
the response to the initial e-mail primarily happened over IPv6.

I wish everybody a great weekend

Enno






-- 
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator

Re: Redploying most of 127/8 as unicast public

[Matthew Walster]

On Sat, 20 Nov 2021 at 13:47, Måns Nilsson 
wrote:

> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20,
> 2021 at 11:16:59AM + Quoting Matthew Walster (matt...@walster.org):
> > 3. IPv6 "port forwarding" isn't really an easy thing -- people are not
> used
> > to each machine having a global address.
>
> This is the problem in a nutshell. After 27 years of destroying the
> E2E model on the internet, people do not anymore understand how IP
> (regardless of version) was supposed to work; any node to any node.
>
> Why should we burden ourselves with this cumbersome and painful, useless
> layer of abstraction that is "port forwarding", when the choice of
> universal reachability is around the corner?
>

Because it's a REALLY bad idea to have unmanaged devices reachable from the
open internet. Dial-out, not dial-in. You need a firewall. You need a way
of punching holes in that firewall for services you explicitly allow, be
that manually through an interface, or temporarily via an automated system
like upnp/nat-pmp.


> If people can set a port forward up, they can click "allow" in a
> routing-based firewall interface. Only it is better, because one can
> have several parallel services using well-known ports. Sometimes (most
> of the time) the protocol spec has no option to change port either,
> making port forwarding futile anyway. (the let's have a TXT record bunch
> at it again, purposefully ignoring SRV since its inception.)
>

It's not always people. Lots of games, lots of telephony things, services
like Syncthing... They all open firewall holes (yes, NAT is a firewall) to
allow inbound connections for specific conditions, like "this protocol and
port combination".


> I guess juggling our pains differently is what we are doing here. What
> is unthinkable to one is quite OK to someone else.
>

Indeed.


> (But I am right)
>

You are not. I'm glad my internet connected light bulbs are controlled by
the Australian firm that manufactures them and the American firm that has a
surveillance device in my kitchen listening for the immortal words "turn on
the living room lights", rather than Billy* from Doncaster who's looking
for something funny to do after losing at CS:GO again and happens to have
found a list of IP addresses of known vulnerable devices accessible from
the internet.

M

*Billy may or may not be a fictional person living in Yorkshire, UK. For
the sake of argument, Not All Yorkshiremen.

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Michael Thomas]

On 11/20/21 12:37 PM, William Herrin wrote:

On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas  wrote:

Was it the politics of ipv6 that
this didn't get resolved in the 90's when it was a lot more tractable?

No, in the '90s we didn't have nearly the basis for looking ahead. We
might still have invented a new way to use IP addresses that required
a block that wasn't unicast. It was politics in the 2000's and the
2010's, as it is today.


In the early to mid 90's it was still a crap shoot of whether IP was 
going to win (though it was really the only game in town for non-lan) 
but by when I started at Cisco in 1998 it was the clear winner with 
broadband starting to roll out. It was also obvious that v4 address 
space was going to run out which of course was the core reason for v6. 
So I don't understand why this didn't get done then when it was a *lot* 
easier. It sure smacks of politics.


Mike

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[William Herrin]

On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas  wrote:
> Was it the politics of ipv6 that
> this didn't get resolved in the 90's when it was a lot more tractable?

No, in the '90s we didn't have nearly the basis for looking ahead. We
might still have invented a new way to use IP addresses that required
a block that wasn't unicast. It was politics in the 2000's and the
2010's, as it is today.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Michael Thomas]

On 11/20/21 11:51 AM, William Herrin wrote:


If I had to guess, changing 224/4 is probably the biggest lift. The
other proposals mainly involve altering configuration, removing some
possibly hardcoded filters and in a few cases waiting for silicon to
age out of the system. Changing 224/4 means following a different code
path which does something fundamentally different with the packets --
unicast instead of multicast.


Yes, I agree it's the hardest. But if you're going to make changes at 
all you might as well get all of them. Was it the politics of ipv6 that 
this didn't get resolved in the 90's when it was a lot more tractable?


Mike

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Michael Thomas]

On 11/20/21 11:41 AM, Jay Hennigan wrote:

On 11/20/21 11:01, Michael Thomas wrote:

There is just as big a block of addresses with class D addresses for 
broadcast. Is broadcast really even a thing these days? I know tons 
of work went into it, but it always seemed that brute force and 
ignorance won out using unicast. Even if it has some niche uses, I 
seriously doubt that it needs 400M addresses. If you wanted to 
reclaim ipv4 addresses it seems that class D and class E would be a 
much better target than loopback.


It's multicast, not broadcast. A very small chunk is used by some 
routing protocols and it has uses in several streaming applications, 
but indeed it's much larger than it practically needs to be.


However, IMNSHO, all of these proposals if adopted are really just 
going to make a few people richer in the short term after their 
adoption and will not do anything significant to solve the problem of 
IPv4 exhaustion long-term.


Yeah, sorry brain fart. I'm mostly in the camp of just getting on with 
it with ipv6, but starving the beast doesn't have a great track record. 
We are talking about 20% of the address space that's being wasted so 
it's not nothing.


Mike

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[John Levine]

It appears that Michael Thomas  said:
>There is just as big a block of addresses with class D addresses for 
>broadcast. Is broadcast really even a thing these days?

It's multicast and no, but it hardly matters.

It's the same problem, if you wanted to turn it into unicast space you'd need
a global forklift upgrade.

FWIW, I see a trickle of class D traffic coming through my router but no class 
E.

R's,
John

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[William Herrin]

On Sat, Nov 20, 2021 at 11:02 AM Michael Thomas  wrote:
> Even if it has some niche uses, I seriously doubt
> that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it
> seems that class D and class E would be a much better target than loopback.

Hi Mike,

If you follow the links there are multiple proposals split by the
address space they apply to. There's one for 240/4 and another for
224/4 in addition to the one we've been discussing for 127/8.

Obviously the one for 240/4 is the lowest hanging fruit of the bunch.

> There is just as big a block of addresses with class D addresses for
> broadcast. Is broadcast really even a thing these days?

Multicast is not the same as broadcast and yes, it's a thing. Mainly
it's a thing confined to the local broadcast domain but in that scope
it's quite widely used. A lot of routing protocols (including OSPF)
use multicast, for example. However, while it's widely used there
aren't very many -different- things using it so only a tiny fraction
of the 224/4 space has been assigned to anything in common use.

If I had to guess, changing 224/4 is probably the biggest lift. The
other proposals mainly involve altering configuration, removing some
possibly hardcoded filters and in a few cases waiting for silicon to
age out of the system. Changing 224/4 means following a different code
path which does something fundamentally different with the packets --
unicast instead of multicast.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Class D addresses? was: Redploying most of 127/8 as unicast public

[Jay Hennigan]

On 11/20/21 11:01, Michael Thomas wrote:

There is just as big a block of addresses with class D addresses for 
broadcast. Is broadcast really even a thing these days? I know tons of 
work went into it, but it always seemed that brute force and ignorance 
won out using unicast. Even if it has some niche uses, I seriously doubt 
that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it 
seems that class D and class E would be a much better target than loopback.


It's multicast, not broadcast. A very small chunk is used by some 
routing protocols and it has uses in several streaming applications, but 
indeed it's much larger than it practically needs to be.


However, IMNSHO, all of these proposals if adopted are really just going 
to make a few people richer in the short term after their adoption and 
will not do anything significant to solve the problem of IPv4 exhaustion 
long-term.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Jim]

On Sat, Nov 20, 2021 at 1:02 PM Michael Thomas  wrote:
> On 11/20/21 10:44 AM, Chris Adams wrote:

> that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it
> seems that class D and class E would be a much better target than loopback.
> Mike, not that I have any stake in this

400M addresses may be excessive,  but not so much the Low-hanging fruit
you seemed to suggest.  May be worth the consideration to reduce,
but need to see your draft standard first,  about what exactly you propose to
reclaim from class D..

Unlike class E and 127/8,  there are many protocols and applications that
communicate between separate devices on a network over class D in a
non-unicast manner to contend with that utilize either official MC assignments,
or Private/org-specific assignments from available class D space

 - Multicast/broadcast addresses used by many control systems such as
routing protocols (VRRP),
camera systems / physical security,  etc.

--
-JH

Class D addresses? was: Redploying most of 127/8 as unicast public

[Michael Thomas]

On 11/20/21 10:44 AM, Chris Adams wrote:

[]

There is just as big a block of addresses with class D addresses for 
broadcast. Is broadcast really even a thing these days? I know tons of 
work went into it, but it always seemed that brute force and ignorance 
won out using unicast. Even if it has some niche uses, I seriously doubt 
that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it 
seems that class D and class E would be a much better target than loopback.


Mike, not that I have any stake in this

Re: Redploying most of 127/8 as unicast public

[Chris Adams]

Once upon a time, Masataka Ohta  said:
> It merely means IPv6 is not deployable with the real reason.

Except that is provably wrong.  A significant number of people are using
IPv6 (and probably don't even know it, because it works without notice).
Almost everything you do on the US cell networks is IPv6.  I'm running
over IPv6 to send this message, or when I go to Google or Facebook or
Netflix for example.

I didn't have to do anything special to get any of that to work; I use
my own CPE (which I didn't have to configure special to get IPv6), but
my provider-provided CPE also supported IPv6 out of the box.  The common
client OSes all support IPv6 out of the box (only major snag I'm aware
of is Android and DHCPv6, c'mon Google, but typical residential CPE does
RA anyway so this only affects larger businesses with managed networks).

Non-general-purpose devices are lagging some, but on the game system
front, Xbox (at least) supports IPv6.  IPv6 support is even in things
like my home audio receiver (Internet connected for streaming music,
which Pandora and Spotify at least support IPv6) and 5+ year old injket
printer.

Could I run IPv6 only today?  No, not quite.  But it's getting closer to
that point every day.  Providers running CG-NAT see that getting IPv6
dual-stack deployed reduces the IPv4 bandwidth (so reduces the CG-NAT
costs) because so much is IPv6-enabled already.

-- 
Chris Adams 

Re: Redploying most of 127/8 as unicast public

[Masataka Ohta]

Mans Nilsson wrote:

Supplying context you omit:

>>> No, it is the real reason that we still have v4 around.

>> Even more than 25 years after IPv6 became a proposed standard?

It merely means IPv6 is not deployable with the real reason.


> IPv6 is deployable. It is deployed.

If you mean ATM is deployable and was deployed, yes, you are
right. So?

>> After finding that, I, as a theorist, totally abandoned IPv6.
> You gave up, based on false conclusions.

Sorry, but I'm not interested in how you falsely recognize the
real world of practical and theoretical internetworking.

Masataka Ohta

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 
at 09:04:38PM +0900 Quoting Masataka Ohta (mo...@necom830.hpcl.titech.ac.jp):
 
> It merely means IPv6 is not deployable with the real reason.

IPv6 is deployable. It is deployed. You are fundamentally in error. Any
conclusions stemming from the false statement "IPv6 is not deployable"
are thus false. While your statements on ports being a part of the address
might hold some value in a world where there is no alternative they are
simply too limited in a world with practically unlimited addresses.
 
> After finding that, I, as a theorist, totally abandoned IPv6.

You gave up, based on false conclusions. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
... I want a COLOR T.V. and a VIBRATING BED!!!


signature.asc
Description: PGP signature

Re: Redploying most of 127/8 as unicast public

[Mark Tinka]

During the nation-wide lockdown of 2020, around the world, I took up 
live-streaming my DJ sets online, since I couldn't play live. For those 
that haven't seen them, you're welcome to my Youtube channel to catch them:


https://yt.djmt.africa/watch

Anyway, what I wanted to say is that I was streaming using an iPhone app 
that turns the iPhone and iPad into a digital video capture device.


As per the links below, if this lowly, rather obscure app from an 
unknown Canadian iOS developer supports IPv6 as a way to setup a remote 
connection between the laptop (encoder) and iPhone/iPad, in order to 
make camera adjustments so you don't have to physically walk toward the 
device, what is your excuse :-)?


https://ibb.co/C8kbpPc
https://ibb.co/yYPWbvd

Mark.

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 
at 11:16:59AM + Quoting Matthew Walster (matt...@walster.org):
 
> The "real" reason we have IPv4 around is that it works. 

It works in our present context, good enough that the pain of moving
looks bad to many people.  This is Ohta-san's argument too. 

> 3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
> to each machine having a global address. 

This is the problem in a nutshell. After 27 years of destroying the
E2E model on the internet, people do not anymore understand how IP
(regardless of version) was supposed to work; any node to any node.

Why should we burden ourselves with this cumbersome and painful, useless
layer of abstraction that is "port forwarding", when the choice of
universal reachability is around the corner?

If people can set a port forward up, they can click "allow" in a
routing-based firewall interface. Only it is better, because one can
have several parallel services using well-known ports. Sometimes (most
of the time) the protocol spec has no option to change port either,
making port forwarding futile anyway. (the let's have a TXT record bunch
at it again, purposefully ignoring SRV since its inception.)

I guess juggling our pains differently is what we are doing here. What
is unthinkable to one is quite OK to someone else.

(But I am right) 
-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
We just joined the civil hair patrol!


signature.asc
Description: PGP signature

Re: Redploying most of 127/8 as unicast public

[Masataka Ohta]

Mans Nilsson wrote:


We cope,
because a lot of technical debt is amassed in corporate and ISP /
access provider networks that won't change.


Sounds like abstract nonsense.


No, it is the real reason that we still have v4 around.


Even more than 25 years after IPv6 became a proposed standard?

It merely means IPv6 is not deployable with the real reason.


The reality is that application servers only need globally unique
and stable IP+Ports.

You can address application servers with them.


If, and that is a big IF, they're designed for that. Hint: They're not,
and I'm required to deploy technology compatible with older systems and
systems outside my control.  It would be far easier for me if I could
continue with the original assumption -- IP addresses are identifiers.


The proper layering, which you insist to ignore, is that IP addresses
are identifiers at the network layer whereas IP+Ports are the
identifiers at above layers.


I know you will immediately state that if I change everything else except
the IP addressing scheme at 32 bits plus 16 bits of port space (which in
and of itself is a change;


It was.

It was the changed made by deploying NAT, which was a lot lot lot
less painful to support IPv6.

> But I only want to change the addressing layer.

There is no such layer as "the addressing layer".

At the transport layer, connections are addressed by network
addresses and port numbers, which means address there in the
Internet is IP+Port.

I really recommend you to understand proper layering.

> In your application, that assertion on worseness might be true. In my,
> where I value the E2E principle higher, no, I think it is not.

So, you are rather a theorist than a practitioner.

However, I'm both of them.

See:

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00

to understand that properly architected NAT preserves the so
valuable E2E principle.

For example, I confirmed with my implementation that PORT command
of ftp perfectly works over the E2E NAT gateways.

After finding that, I, as a theorist, totally abandoned IPv6.

Masataka Ohta

Re: Redploying most of 127/8 as unicast public

[Matthew Walster]

On Sat, 20 Nov 2021, 09:21 Måns Nilsson,  wrote:

> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20,
> 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (
> mo...@necom830.hpcl.titech.ac.jp):
>
> > > We cope,
> > > because a lot of technical debt is amassed in corporate and ISP /
> > > access provider networks that won't change.
> >
> > Sounds like abstract nonsense.
>
> No, it is the real reason that we still have v4 around.
>

The "real" reason we have IPv4 around is that it works. Having IPv4+IPv6 is
relatively easy, but dropping IPv4 to run IPv6 only is difficult. Some
examples:

***

1. Your power goes out. When it comes back up, your internet connection is
down. You want to log in to the router... Except you can't. You don't know
the address, and you won't have one until your ISP gives you one via DHCP
(or similar).

Sure, you could maybe provide the link-local address on the bottom of the
router, but expecting a user to get http://[fe80:211:aaff:febb:ccdd] right
(and you might even need interface scoping!) is boring to cause user
frustration when an ISP tech support tries to help, and having the provided
CPE using fe80::1 is probably a recipe for disaster.

Likewise, having an mdns broadcast (h, I know) for "gateway" or
"router" is definitely not something standardised.

2. Your IPv6 prefix changes. With some ISPs, it can change every time your
router reboots, and if you're with my ISP, it crash-reboots about once a
week! If your CPE isn't providing your WiFi (range extender, mesh, nerd
etc) then the old prefix is still valid for a while. Yes, there's an RFC to
deal with this, but realistically it's not out there today.

Also, any local services are going to break if they're on static
addresses... I'm not just talking enterprise AD servers etc, it's also CCTV
cameras, raspberry pis, NAS units etc. DHCP registration of addresses in
DNS exists, yes, but it's just not used by most of these devices.

This could easily be fixed by having a well-known (and short/memorable!)
/48 set aside that would have NAT66 (1:1, not port overload) applied at the
router to the delegated prefix received from the ISP, but I'll be shouted
down to hell for even mentioning that idea.

3. IPv6 "port forwarding" isn't really an easy thing -- people are not used
to each machine having a global address. Sure, on many devices you can add
firewall rules to allow traffic in, but it's not like the "port forwarding"
concept people have gotten used to. I genuinely have no idea whether
upnp/nat-pmp has an IPv6 analogue that "just works" which things like
consoles (or apps like syncthing) can take advantage of.

***

IPv4 works. There is no appreciable benefit to the user in enabling IPv6,
but the ISP does it and it just works. The same can't be said of going IPv6
only -- you can easily provide IPv6 only with NAT64 and DNS64 or some
XLAT464 fun when you're dealing with public WiFi, but this is people's
homes and businesses.

Likewise, there's so many devices that are IPv4 only, and aren't getting
retired anytime soon. In fact, there's a lot of devices released in the
last few years that fully support IPv6, but only when it also has an IPv4
address. I believe either the new Xbox and/or PS5 fit into that category.

IPv4 is getting more expensive for ISPs because of addressing costs, but a
5-tuple CGNAT solution capable of saturating a 100Gb/s pipe is under $10k
these days if you're doing it on the cheap. Yes, this is massively
oversimplified.

Not just that, if you have a CPE capable of doing MAP-T (RFC7599 et al)
then your CGNAT doesn't even need to track state, and you can probably do
it in ASIC, especially with a programmable dataplane (P4 etc).

IPv6 only is the goal. IPv4 is going to be with us for at least a decade.
Getting IPv6 up and running on a network requires a lot of effort when that
network is run by the IT PFY, but it will slowly get that wide penetration
desired... Turning off IPv4 for your regular residential and SME ISP
connections is such a PITA fraught with support problems that it is just
not practical outside of very limited conditions.

Certainly, on the content side, you can make all your HTTP services on IPv6
only servers, and have the IPv4 go to a proxy that routes based on Host
header or SNI, but you need some networking knowledge already to understand
what is going on there.

IPv4 isn't going anywhere anytime soon. Enabling IPv6 reduces IPv4 traffic
levels, it does not reduce IPv4 address usage.

Happy for someone to prove me wrong here, but don't use mobile as an
example. That's a very different market... I'm talking about residential
and SOHO internet access here only.

M

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 
at 10:26:33AM +0900 Quoting Masataka Ohta (mo...@necom830.hpcl.titech.ac.jp):
 
> > We cope,
> > because a lot of technical debt is amassed in corporate and ISP /
> > access provider networks that won't change.
> 
> Sounds like abstract nonsense.

No, it is the real reason that we still have v4 around. 
 
> > We don't cope because NAT is
> > good. Hardly a workday goes past without me thinking "If I could address
> > this computer uniquely I'd go home earlier and with less grey hair".
> 
> The reality is that application servers only need globally unique
> and stable IP+Ports.
> 
> You can address application servers with them.

If, and that is a big IF, they're designed for that. Hint: They're not,
and I'm required to deploy technology compatible with older systems and
systems outside my control.  It would be far easier for me if I could
continue with the original assumption -- IP addresses are identifiers.

I know you will immediately state that if I change everything else except
the IP addressing scheme at 32 bits plus 16 bits of port space (which in
and of itself is a change; granted more so in terms of service location),
I will be fine. But I only want to change the addressing layer. The rest
works fine. And is a bigger mess to alter to your idea. 
 
> > We must do better.
> 
> As IPv6 is worse than IPv4 with NAT, feel free to propose a new
> network protocol.

In your application, that assertion on worseness might be true. In my,
where I value the E2E principle higher, no, I think it is not. 


-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
I used to be a FUNDAMENTALIST, but then I heard about the HIGH
RADIATION LEVELS and bought an ENCYCLOPEDIA!!


signature.asc
Description: PGP signature

Re: Redploying most of 127/8 as unicast public

[Masataka Ohta]

Mans Nilsson wrote:


With proper layering, network addresses including IP ones, certainly,
uniquely identify *hosts*.

However, with proper layering, *applications* only require uniqueness
of IP+Port, which is enough for the worldwide IPv4 network.

As a result, NAT won the battle against IPv6.

IPv6 addresses are free but useless.


With all due respect, you think about networks. I use and build
networks. And my experience is that IP+port is not enough.


Certainly, local uniqueness of IP addresses to identify hosts
is required even in private networks behind NAT. But, because
of layering, that's all.

I do have extensive experiences to use and build networks
with proper layering in mind.


We cope,
because a lot of technical debt is amassed in corporate and ISP /
access provider networks that won't change.


Sounds like abstract nonsense.


We don't cope because NAT is
good. Hardly a workday goes past without me thinking "If I could address
this computer uniquely I'd go home earlier and with less grey hair".


The reality is that application servers only need globally unique
and stable IP+Ports.

You can address application servers with them.


We must do better.


As IPv6 is worse than IPv4 with NAT, feel free to propose a new
network protocol.

Masataka Ohta

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Fri, Nov 19, 2021 
at 09:04:59PM +0900 Quoting Masataka Ohta (mo...@necom830.hpcl.titech.ac.jp):
> Mans Nilsson wrote:
> 
> > The essence of an IP address is that it is unique. The larger the network
> > area is that recognizes it as unique, the better it is.
> 
> With proper layering, network addresses including IP ones, certainly,
> uniquely identify *hosts*.
> 
> However, with proper layering, *applications* only require uniqueness
> of IP+Port, which is enough for the worldwide IPv4 network.
> 
> As a result, NAT won the battle against IPv6.
> 
> IPv6 addresses are free but useless.

With all due respect, you think about networks. I use and build
networks. And my experience is that IP+port is not enough. We cope,
because a lot of technical debt is amassed in corporate and ISP /
access provider networks that won't change. We don't cope because NAT is
good. Hardly a workday goes past without me thinking "If I could address
this computer uniquely I'd go home earlier and with less grey hair".

We must do better. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
Do you have exactly what I want in a plaid poindexter bar bat??


signature.asc
Description: PGP signature

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Fri, Nov 19, 2021 
at 12:26:23PM -0800 Quoting John Gilmore (g...@toad.com):
> =?utf-8?B?TcOlbnM=?= Nilsson  wrote:
> > The only viable future is to convert [to IPv6].  This is not
> > group-think, it is simple math.
> 
> OK.  And in the long run, we are all dead.  That is not group-think, it
> is simple math.  Yet that's not a good argument for deciding not to
> improve our lives today.  Nor to fail to improve them for tomorrow,
> in case we live til then.

The math is true today. Most people now have more devices than they have
IP addresses. (And reachability should be choice, not shortage
consequence) Increasing the available address space by at most a few
percent at the price of a flag day is not a good return. (unless you
are in a position to profit from the shortage, at which point all these
crutch proposals look irresistible if not from a technical standpoint)
Increasing the address space 79228162514264337593543950336 times at
the price of rolling software upgrades that actually mostly are done
(I haven't bought or commissioned non-v6 gear for 15 years now), even
if there's a lot left to turn on and configure, is a slightly better
proposition.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
MY income is ALL disposable!


signature.asc
Description: PGP signature

Re: Redploying most of 127/8 as unicast public

[John Gilmore]

=?utf-8?B?TcOlbnM=?= Nilsson  wrote:
> The only viable future is to convert [to IPv6].  This is not
> group-think, it is simple math.

OK.  And in the long run, we are all dead.  That is not group-think, it
is simple math.  Yet that's not a good argument for deciding not to
improve our lives today.  Nor to fail to improve them for tomorrow,
in case we live til then.

John  

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Owen DeLong wrote:



LLA and ULA and whatever random prefix you may wish to use for loopback, 
whether in IPv6 or even IPv4 have none of these qualities.

And if we implement the proposal at hand, which as near as I can tell you are 
supporting, that changes.

Having trouble following your desired outcome here. It seems as if you both 
want 127.0.0.0/8 to retain it’s unique properties
as deterministically loopback only and also want the benefits of repurposing it 
as GUA.

Have cake, Eat cake, please to pick only one.


Let me clear that up then.

I support serious consideration of the idea. My desired outcome is to 
see ideas like these either adopted or not but based solely on their own 
merits and especially in their own protocol context. And that folk who 
have studied the issue and invested their efforts be taken seriously and 
not be met with undeserved and might I add, unkind, scorn.


(I havent studied the issue or invested the effort, so you may continue 
to direct your scorn this way)


Its well past time to stop behaving as if we are a bunch of teenagers on 
a private BBS.


I like the loopback prefix feature of IPv4.

I can easily concede that its too large, especially in this day and age. 
And that there is a good chance that significant benefit can come from 
addressing that before IPv4 becomes obsolete.


I question the lack of dedicated loopback feature in IPv6 and I 
acknowledge that yes, you can accomplish the same with non loopback 
prefixes by essentially assigning them to loopback, but point out that 
that does not make them the same thing.


I can understand that sometimes you may explicitly not want to use the 
loopback prefix for loopback applications. In fact many times. However, 
you dont really have much options when it comes to IPv6.


And I discuss IPv6 loopback simply because of the pushback directed in a 
non-meritorious fashion from folk who apparently believe simultaneously 
that IPv6 is superior in every way to IPv4 and that any 
improvements|changes to IPv4 somehow endanger IPv6 imminent dominance.



  having a prefix
dedicated to that purpose globally vs. allowing each site that cares to choose 
their own doesn’t seem like the best
tradeoff.

Owen


But this is how it is to be done in IPv6, so lets get some lack-of-feature 
parity going with IPv4.

I’m all for IPv6 having better implementations than IPv4 rather than mere 
feature parity.



Actually I am (somewhat facetiously) suggesting that IPv4 have 
non-feature parity with IPv6 by taking away its loopback prefix.





IMHO, having additional loopbacks be assigned from either LLA or ULA space (or 
even GUA, really)
where that is needed is a superior choice vs. 127.0.0.0/8.


Anyone who wants to assign routable IPv4 to loopback is free to do so 
and there are plenty of IPv4 ranges to choose from.


The converse is not true in IPv6.


For one thing, the alternative addressing schemes (other than LLA) allow for 
routing of the
addresses off the box even though they are configured on loopback interfaces. 
There are
a number of situations where this can be a useful way to ensure that the 
addresses remain
usable regardless of the up/down state of connectivity on any particular 
non-loopback
interface on the box.

It’s one of the reasons, for example, that virtually every IBGP speaking router 
has a GUA
or ULA/1918 loopback address which is routed in the IGP and almost all IBGP 
sessions
are terminated on those loopback interfaces.

Owen

And its the fairly common way of implementing anycast services. But that 
is not what we are addressing on this thread.


I actually think that IPv6 evangelicals should welcome any all ideas 
like this, especially if they believe it will further degrade the 
overall state of IPv4, because that should only serve as stronger 
impetus for IPv6 deployment. That mode of thought has been commonly 
expressed here and other places before.


Best,

Joe

Re: Redploying most of 127/8 as unicast public

[Dave Taht]

On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG  wrote:
> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not 
> particularly widespread, having a prefix
> dedicated to that purpose globally vs. allowing each site that cares to 
> choose their own doesn’t seem like the best
> tradeoff.

I would prefer to discuss the other drafts. However, - and this is not
in the 127 draft, and is an opinion not shared with the other authors
-
I have a specific use case for making 127 "more routable", in that
there is nowadays a twisty maze of microservices, bottled up in a
variety of
kubernetes containers, running on top of vms, on top of a hypervisor,
that are often hooked together via rfc1918 addressing and NAT.

Trying to figure out that particular path, from within one of those
containers, can be a PITA. The concept of 127 being local to a
physical host
(and routed internally, rather than natted), where those twisty maze
of services ideally remains within that host, holds some appeal to me.

>
> Owen
>


-- 
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: Redploying most of 127/8 as unicast public

[Greg Skinner via NANOG]

For what it’s worth, it's also being discussed in a couple of subreddits.  
Total # of comments is about 500, so far.

https://www.reddit.com/r/sysadmin/comments/qvuyor/new_rfc_to_redefine_loop_back_and_allow_127100_to/
 

https://www.reddit.com/r/networking/comments/qw0kv0/unicast_use_of_the_formerly_reserved_1278/
 


—gregbo

Re: Redploying most of 127/8 as unicast public

[Jay R. Ashworth]

So see, that was kinda my view, though I hadn't realized there was a kernel
hack advancing the football...

- Original Message -
> From: "Owen DeLong" 
> To: "William Herrin" 
> Cc: "jra" , "nanog" 
> Sent: Friday, November 19, 2021 9:28:01 AM
> Subject: Re: Redploying most of 127/8 as unicast public

> This will break a significant number of existing deployments where people
> have come to depend on a feature in Linux where any address within 127.0.0.0/8
> can be “listened” and operate as a valid loopback address without configuring
> the addresses individually as unicast on the interface.
> 
> In fact, this is true of any prefix assigned to the loopback interface, but
> 127.0.0.0/8
> is automatic and difficult to change.
> 
> While I’m not sure this implementation in the Linux kernel was such a 
> wonderful
> idea, it is widely deployed and in use in a number of environments.
> 
> If we’re still using IPv4 widely enough that GUA space matters, we will have
> far bigger problems than the lack of available GUA for it.
> 
> Owen
> 
> 
>> On Nov 17, 2021, at 16:15 , William Herrin  wrote:
>> 
>> On Wed, Nov 17, 2021 at 3:31 PM Jay R. Ashworth  wrote:
>>> This seems like a really bad idea to me; am I really the only one who 
>>> noticed?
>>> 
>>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>> 
>> Hi Jay,
>> 
>> I think it's a good idea. It won't be usable any time in the next two
>> decades but if we're still using IPv4 in two decades we'll be glad to
>> have anything we can scrounge. Why not ask OS authors to start
>> assigning 127.0.0.1/16 to loopback instead of 127.0.0.1/8?
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> --
>> William Herrin
>> b...@herrin.us
> > https://bill.herrin.us/

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Redploying most of 127/8 as unicast public

[William Herrin]

On Fri, Nov 19, 2021 at 8:35 AM Owen DeLong via NANOG  wrote:
> I’m all for IPv6 having better implementations than IPv4 rather than mere 
> feature parity.

Me too, just not in a dystopian Harrison Bergeron sort of way.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 19, 2021, at 07:39 , Joe Maimon  wrote:
> 
> 
> 
> Owen DeLong wrote:
>> 
>>> On Nov 17, 2021, at 21:33 , Joe Maimon  wrote:
>>> 
>>> 
>>> And I think the basic contention is that the vast majority of 127/8 is not 
>>> in use. Apples to oranges, indeed.
>> This contention is provably false for some definitions of “in use”.
> 
> Determining the extent of this would be part of serious consideration.
>> 
>> In what way would the LLA or ULA above be meaningfully different from 127/8 
>> as deployed?
> 
> Because 127/8 is the exact same number on every system and it is routed the 
> same way on every system and every system can choose to use it how it and it 
> alone wishes to.

But the proposal seeks to change that nature of 127.0.0.0/8 to make it more 
like LLA/ULA, so…

> So this make it a deterministic prefix solely in control of the local system 
> without any external context to ever be taken into consideration, by 
> convention and standard.

At the moment, that’s already true. AIUI, the proposal being discussed seeks to 
convert 127.0.0.0/8 outside of 127.0.0.1 (or at least outside of 127.0.0.0/16) 
into
routable GUA.

> LLA and ULA and whatever random prefix you may wish to use for loopback, 
> whether in IPv6 or even IPv4 have none of these qualities.

And if we implement the proposal at hand, which as near as I can tell you are 
supporting, that changes.

>>> Doesnt IPv6 deserve its own instead of squatting on IPv4?
>> I don’t see any “squatting on IPv4” here.
> 
> It means that the only deterministic loopback prefix in IPv6 larger than a 
> single address is the one IPv6 inherited from IPv4.

Well… Worst case, it could use :::7f00:::/96

Whether you consider that “squatting on IPv4” or not is left as an exercise to 
the reader. I do not, though I can understand and
must admit that it is equally legitimate if someone else does.

>> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not 
>> particularly widespread,
> 
> This is not my point, it is the contention of the draft standard and it is 
> something I would hope is taken into serious consideration and researched 
> properly/
> 
> My point is that to the extent this is true, the value of the space for other 
> purposes could very well warrant re-purposing.

Having trouble following your desired outcome here. It seems as if you both 
want 127.0.0.0/8 to retain it’s unique properties
as deterministically loopback only and also want the benefits of repurposing it 
as GUA.

Have cake, Eat cake, please to pick only one.

>>  having a prefix
>> dedicated to that purpose globally vs. allowing each site that cares to 
>> choose their own doesn’t seem like the best
>> tradeoff.
>> 
>> Owen
>> 
> But this is how it is to be done in IPv6, so lets get some lack-of-feature 
> parity going with IPv4.

I’m all for IPv6 having better implementations than IPv4 rather than mere 
feature parity.

IMHO, having additional loopbacks be assigned from either LLA or ULA space (or 
even GUA, really)
where that is needed is a superior choice vs. 127.0.0.0/8.

For one thing, the alternative addressing schemes (other than LLA) allow for 
routing of the
addresses off the box even though they are configured on loopback interfaces. 
There are
a number of situations where this can be a useful way to ensure that the 
addresses remain
usable regardless of the up/down state of connectivity on any particular 
non-loopback
interface on the box.

It’s one of the reasons, for example, that virtually every IBGP speaking router 
has a GUA
or ULA/1918 loopback address which is routed in the IGP and almost all IBGP 
sessions
are terminated on those loopback interfaces.

Owen

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 19, 2021, at 07:23 , Dave Taht  wrote:
> 
> On Fri, Nov 19, 2021 at 7:00 AM Owen DeLong via NANOG  wrote:
>> Since, as you point out, use of the other addresses in 127.0.0.0/8 is not 
>> particularly widespread, having a prefix
>> dedicated to that purpose globally vs. allowing each site that cares to 
>> choose their own doesn’t seem like the best
>> tradeoff.
> 
> I would prefer to discuss the other drafts. However, - and this is not
> in the 127 draft, and is an opinion not shared with the other authors
> -
> I have a specific use case for making 127 "more routable", in that
> there is nowadays a twisty maze of microservices, bottled up in a
> variety of
> kubernetes containers, running on top of vms, on top of a hypervisor,
> that are often hooked together via rfc1918 addressing and NAT.
> 
> Trying to figure out that particular path, from within one of those
> containers, can be a PITA. The concept of 127 being local to a
> physical host
> (and routed internally, rather than natted), where those twisty maze
> of services ideally remains within that host, holds some appeal to me.

Couldn’t you do this with 169.254.0.0/16 (or IPv6 GUA or ULA)
just as easily without the need to rewrite virtually every layer of the
stack of miscellaneous software defined networking stuff you just listed?

Owen

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> 
> You are proposing a deal involving paper money you have on your person
> to your fellow passengers on the Titanic; that is the essence of your
> proposed bet hedging. Having studied the market for IPv4, it is a no-
> brainer to realise the driving force behind all these schemes. Delaying
> the inevitable is just going to make some people richer, to the detriment 
> of others.  I see no reason to support that. 

That’s because you and I are probably on the wrong side of the benefit/detriment
divide.

No doubt those pushing the proposal(s) think they have a way to be on the
benefit side of said divide.

Owen

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Joe Maimon]

Owen DeLong via NANOG wrote:

I don’t see the difference between 6 and 7 usable addresses on all the /29s
in the world as actually making a significant impact on the usable lifespan of
IPv4.

Owen



This idea gets better each time I think about it. The changes and 
support required would typically be only local to customer/vendor and it 
can be useful in multiple contexts within a single entity as well.


Or how about this one. I can add VRRP failover to every customer prefix 
with zero negative impact to them by addressing the secondary with the 
all-zero address. Only I have to upgrade since the customer doesnt use 
or refer to that address ever. Now granted, using a FHRP protocol that 
didnt require any address at all in the subnet for the non-primary would 
give the same result. And maybe maybe maybe ICMP from the secondary 
might get dropped by non-updated customer.


How about customers who like to have redundant routers now only require 
an update to do it within /30, which within vendor relationship context, 
should it be standard long enough, they may very well require, and 
should a /29 cost more, the customer may very well prefer.


Getting an extra address out of a /29 and two instead of one out of /30 
can be quite useful to each individual user and use of those prefixes.


Collectively, it may or may not extend IPv4 global resources. Probably 
not in any measurable way and possibly non existent, although it is 
conceivable that /30 would become usable enough that less /29's will be 
assigned, and the same for /29 lasting longer before requiring /28. 
Probably not much beyond that.


Its about getting more mileage from existing allocations, not really 
about making more allocations available.


And all thats needed to be done is to drop this ridiculous .0 for 
broadcast compatibility from standards.why is this even controversial?


Joe

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Owen DeLong wrote:



On Nov 17, 2021, at 21:33 , Joe Maimon  wrote:


And I think the basic contention is that the vast majority of 127/8 is not in 
use. Apples to oranges, indeed.

This contention is provably false for some definitions of “in use”.


Determining the extent of this would be part of serious consideration.


In what way would the LLA or ULA above be meaningfully different from 127/8 as 
deployed?


Because 127/8 is the exact same number on every system and it is routed 
the same way on every system and every system can choose to use it how 
it and it alone wishes to.


So this make it a deterministic prefix solely in control of the local 
system without any external context to ever be taken into consideration, 
by convention and standard.


LLA and ULA and whatever random prefix you may wish to use for loopback, 
whether in IPv6 or even IPv4 have none of these qualities.





Doesnt IPv6 deserve its own instead of squatting on IPv4?

I don’t see any “squatting on IPv4” here.


It means that the only deterministic loopback prefix in IPv6 larger than 
a single address is the one IPv6 inherited from IPv4.


Since, as you point out, use of the other addresses in 127.0.0.0/8 is not 
particularly widespread,


This is not my point, it is the contention of the draft standard and it 
is something I would hope is taken into serious consideration and 
researched properly/


My point is that to the extent this is true, the value of the space for 
other purposes could very well warrant re-purposing.

  having a prefix
dedicated to that purpose globally vs. allowing each site that cares to choose 
their own doesn’t seem like the best
tradeoff.

Owen


But this is how it is to be done in IPv6, so lets get some lack-of-feature 
parity going with IPv4.

Joe

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

I don’t see the difference between 6 and 7 usable addresses on all the /29s
in the world as actually making a significant impact on the usable lifespan of
IPv4.

Owen


> On Nov 17, 2021, at 19:33 , Dave Taht  wrote:
> 
> I am sad to see the most controversial of the proposals (127/16) first
> discussed here.
> 
> Try this instead?
> 
> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/
> 
> in my mind, has the most promise for making the internet better in the
> nearer term.
> 
> Could I get y'all to put aside the 127 proposal and read that over, instead?
> 
> ...
> 
> It's ok, I'll wait...
> 
> ...
> 
> There were two other proposals concerning 240/4 and 0/8 also worth
> reading for their research detail and attention to history.
> 
> The amount of work required to make 240/4 work in most places is now
> very close to zero, having been essentially completed a decade ago.
> 240/4 and 0/8 checking is not present in the SDN codes we tried, and
> we ripped the 0/8 check out of linux 3? 4? years back. Saves a few ns.
> 
> All but one iOt stack we tried worked with these, many of those stacks
> still lack, or have poor ipv6 support. esp32 anyone?
> 
> Just as ipv6 today is not globally reachable, these address spaces may
> never be globally reachable, but defining a standard for their
> potential sub-uses
> seems like a viable idea.

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

Can you be more specific about what changes to IPv6 you believe would resolve 
the issue?

Owen


> On Nov 18, 2021, at 01:43 , b...@uu3.net wrote:
> 
> No, you are not alone. This just gets kinda pathetic.
> It also shows how an IPv6 is a failure.
> (No please, leave me alone all you IPv6 zealots).
> 
> I think its time to go back to design board and start
> working on IPv8 ;) so we finnaly get rid of IPv4...
> 
> -- Original message --
> 
> From: Jay R. Ashworth 
> To: nanog 
> Subject: Redploying most of 127/8 as unicast public
> Date: Wed, 17 Nov 2021 23:29:49 + (UTC)
> 
> This seems like a really bad idea to me; am I really the only one who noticed?
> 
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
> 
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me.  So many things are just me.
> 
> [ Hat tip to Lauren Weinstein, whom I stole it from ]
> 
> Cheers,
> -- jra
> 
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates   http://www.bcp38.info  
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 17, 2021, at 21:33 , Joe Maimon  wrote:
> 
> 
> 
> Mark Andrews wrote:
>> 
>>> On 18 Nov 2021, at 11:58, Joe Maimon  wrote:
>>> 
>>> 
>>> 
>>> Mark Andrews wrote:
 It’s a denial of service attack on the IETF process to keep bringing up 
 drafts like this that are never going to be approved.  127/8 is in use.  
 It isn’t free.
>>> There are so many things wrong with this statement that I am not even going 
>>> to try to enumerate them.
>>> 
>>> However suffice it to say that drafts like these are concrete documentation 
>>> of non-groupthink and essentially you are advocating for self-censorship 
>>> and loss of historical perspective.
>> I’m advocating for not taking address away that have been allocated for a 
>> purpose.  No one knows what the impact of doing that will be.  Perhaps we 
>> should just take back 216.222.144.0/20?  You obviously think taking back 
>> address that are in use to be a good thing.  This is similar to taking back 
>> other address that are allocated but not advertised.
> 
> I am advocating for serious discussion on the merits, and only the merits, of 
> each individual idea and proposal and to respect those willing to put in the 
> effort even while likely knowing of the undeserved scorn bound to come their 
> way from those who choose not do as I would advocate them doing.
> 
> And I think the basic contention is that the vast majority of 127/8 is not in 
> use. Apples to oranges, indeed.

This contention is provably false for some definitions of “in use”.

>> You can script is to the same extent that you can hard code 127/8 addresses. 
>>  I’ve used ULA addresses but conceptually they are the same.  The lo0 
>> interface also has more that 127.0.0.1 IPv4 addresses on it.
>> 
>> % ifconfig lo0 inet6
>> lo0: flags=8049 mtu 16384
>>  options=1203
>>  inet6 ::1 prefixlen 128 .
>>  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
>>  inet6 fd92:7065:b8e:::1 prefixlen 64
>> 
> Thats twice now you have suggested that ULA and LLA are an exact substitute 
> for dedicated system loopback prefix.

In what way would the LLA or ULA above be meaningfully different from 127/8 as 
deployed?

> At the very least, it is semantically not.

How so?

> Doesnt IPv6 deserve its own instead of squatting on IPv4?

I don’t see any “squatting on IPv4” here.

Since, as you point out, use of the other addresses in 127.0.0.0/8 is not 
particularly widespread, having a prefix
dedicated to that purpose globally vs. allowing each site that cares to choose 
their own doesn’t seem like the best
tradeoff.

Owen

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 17, 2021, at 19:40 , Jerry Cloe  wrote:
> 
>  
>  
> Subject: Redploying most of 127/8 as unicast public
> To: nanog mailto:nanog@nanog.org>>; 
> This seems like a really bad idea to me; am I really the only one who noticed?
> 
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html 
> <https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html>
>  
> I can think of about a dozen /8's that would be better to use. (Hint, they 
> all have DOD in the name.) They haven't been in routing tables for decades 
> and there wouldn't be hardly any technical issues (like there would be with 
> 127/8). The only drawback is I've seen a lot of organizations treat them like 
> rfc1918 space.
>  

You are assuming facts not in evidence.

The fact that a prefix isn’t in a routing table you can see does not mean it is 
not used in a circumstance where
having it appear in routing tables you can see would be harmful or disruptive.

Owen

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 17, 2021, at 19:03 , John Levine  wrote:
> 
> It appears that Joe Maimon  said:
>> Mark Andrews wrote:
>>> It’s a denial of service attack on the IETF process to keep bringing up 
>>> drafts like this that are never going to be approved.  127/8 is
>> in use.  It isn’t free.
>> 
>> There are so many things wrong with this statement that I am not even 
>> going to try to enumerate them.
> 
> Aw, c'mon, don't leave us guessing.
> 
>> For example 
>> https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 from 2008 
>> which fell prey to the "by the time this is usable IPv6 will have taken 
>> over" groupthink.
>> 
>> Objectively wrong.
> 
> I will agree that your explanation of the reasons the IETF didn't repurpose 
> 240/8 is objectively wrong.
> 
> The amount of work to change every computer in the world running
> TCP/IP and every IP application to treat 240/4 as unicast (or to treat
> some of 127/8) is not significantly less than the work to get them to
> support IPv6. So it would roughly double the work, for a 2% increase
> in the address space, or for 127/8 less than 1%.  The code for IPv6
> is already written, after all.

There is an (admittedly questionable) argument to be made that application 
updates would not
have been necessary for this, just every OS/Computer/Router/Switch/IDS/IPS/etc.

> Also, while the world has run out of free IPv4 address space, there is
> plenty of IPv4 if you are willing to pay for it. A 2% increase in v4
> addresses would not change that.

In fact, the world has not run out, AFRINIC still has a free pool. 
Unfortunately in an astonishing display
of collective “don’t get it”, they’ve deployed protectionist policies that make 
it incredibly difficult to get
addresses from AFRINIC, ensuring that while the continent still suffers from 
the same level of IPv4
address shortage as the rest of the world, the illusion of a useful free pool 
there will remain for years
to come.

>>> "By contrast, IPv6, despite its vastly larger pool of available address 
>>> space, allocates only a single local loopback address (::1)
>> [RFC4291]. This appears to be an architectural vote of confidence in the 
>> idea that Internet protocols ultimately do not require millions of
>> distinct loopback addresses.”
>>> 
>>> This is an apples-to-oranges comparison.  IPv6 has both link and site local 
>>> addresses and an architecture to deliver packets to specific
>>> instances of each.  This does not exist in the IPv4 world.

Site local was deprecated many many years ago.

>> SO an IPv6 only system without any network interfaces can run multiple 
>> discrete instances of the same daemon accepting connections on the same 
>> TCP port?

Depends on your definition of “without any network interfaces”, since 
technically the loopback interface is a network interface.

If you mean “an IPv6 system with no interfaces other than loopback”, then yes, 
it can because you are free to assign additional
addresses to the loopback interface, but ::1/128 is the only address 
universally assigned to the loopback interface.

> Sure.
> 
>> Can I script that, can I template that with hardcoded 
>> addresses, same as I can now for 127/8?
> 
> Sure, if you think that's a good idea which it isn't.  Use LLAs on your 
> loopback interface.

On a system with no network interfaces other than loopback, it really doesn’t 
matter what you do… LLA, ULA, and GUA
could be used in any combination without negative impact. Nothing is leaving 
the box, so it might as well be an entire
IPv6 internet unto itself.

> Personally, I take my 127/8 addresses from a configuration file since I don't 
> know in advance what
> other daemons might also want to run on addresses only visible on the local 
> machine.  Or, you know,
> some maniac might decide that part of 127/8 isn't loopback so I have to move 
> them to the part that
> still is.

Meh. I think individually assigning addresses for those cases isn’t the worst 
thing in the world, but there are some
circumstances in which the linux kernel’s unique behavior in this regard can be 
convenient.

> In IPv6 I use ULAs since that gives me the option of routing them or not.

Well… I use GUAs because that gives me the option of routing them widely or 
narrowly or not.

ULAs don’t have the option to route them widely without resorting to at least 
NPT which is nearly as hideous as NAPT.

Owen

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

> On Nov 17, 2021, at 16:32 , Sean Donelan  wrote:
> 
> On Wed, 17 Nov 2021, Jay R. Ashworth wrote:
>> That's over a week old and I don't see 3000 comments on it, so maybe it's 
>> just
>> me.  So many things are just me.
> 
> Someone is wrong on the Internet.
> https://xkcd.com/386/
> 
> Other problems which will occur sooner:
> 
> 1. Unix 32-bit time_t overflow.
> 2. North American Numbering Plan runs out of +1 zone phone numbers
> 3. IPv6 deployed and working everywhere/everything on the Internet

How is this a problem?

> 4. Analog AM and FM radio broadcasting deprecated (see digital DAB/DRM/HD)
> 5. Heat death of the universe
> 
> Again, covered by XKCD
> https://xkcd.com/2240/
> 
> I've got other things to do first.

Re: Redploying most of 127/8 as unicast public

[Owen DeLong via NANOG]

This will break a significant number of existing deployments where people
have come to depend on a feature in Linux where any address within 127.0.0.0/8
can be “listened” and operate as a valid loopback address without configuring
the addresses individually as unicast on the interface.

In fact, this is true of any prefix assigned to the loopback interface, but 
127.0.0.0/8
is automatic and difficult to change.

While I’m not sure this implementation in the Linux kernel was such a wonderful
idea, it is widely deployed and in use in a number of environments.

If we’re still using IPv4 widely enough that GUA space matters, we will have
far bigger problems than the lack of available GUA for it.

Owen


> On Nov 17, 2021, at 16:15 , William Herrin  wrote:
> 
> On Wed, Nov 17, 2021 at 3:31 PM Jay R. Ashworth  wrote:
>> This seems like a really bad idea to me; am I really the only one who 
>> noticed?
>> 
>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
> 
> Hi Jay,
> 
> I think it's a good idea. It won't be usable any time in the next two
> decades but if we're still using IPv4 in two decades we'll be glad to
> have anything we can scrounge. Why not ask OS authors to start
> assigning 127.0.0.1/16 to loopback instead of 127.0.0.1/8?
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Redploying most of 127/8 as unicast public

[Masataka Ohta]

Mans Nilsson wrote:


The essence of an IP address is that it is unique. The larger the network
area is that recognizes it as unique, the better it is.


With proper layering, network addresses including IP ones, certainly,
uniquely identify *hosts*.

However, with proper layering, *applications* only require uniqueness
of IP+Port, which is enough for the worldwide IPv4 network.

As a result, NAT won the battle against IPv6.

IPv6 addresses are free but useless.

Masataka Ohta

Re: Redploying most of 127/8 as unicast public

[William Herrin]

On Thu, Nov 18, 2021 at 11:20 PM Måns Nilsson  wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Thu, Nov 18, 
> 2021 at 01:46:04PM -0800 Quoting William Herrin (b...@herrin.us):
> > The detractors for this proposal and those like it make the core claim
> > that we shouldn't take the long view improving IPv4 because IPv6 is
> > going to replace it any day now. Each day that passes with the end of
> > IPv4 still not in sight demonstrates how very wrong that strategy is.
>
> Aw, come on. There is noone (except naive ones in power) who expect this
> to happen immediately.  We all knew there would be a transition
> period. The "improvement" part was CIDR. And a very good one it is at
> that -- it sort of sets the standard as to what an improvement should
> be to count. 6,25% new addresses from Net 240 is not an improvement in
> that regard, and neither would the much smaller contribution from Net
> 127 be. Both are no more than holding paper money on the deck of the
> Titanic.
>
> The essence of an IP address is that it is unique. The larger the network
> area is that recognizes it as unique, the better it is. That's why RFC
> 1918 is free and useless.  We all know this.
>
> The only viable future is to convert.  This is not group-think, it is simple 
> math.
>
> > If there's a change we can make to a standard now which will result in
> > IPv4 being better 20 years from now, we should make it. We should hope
> > that we never need the result because IPv6 takes over the world but we
> > should make the change anyway. Because hedging our bets is what
> > responsible people do.
>
> You are proposing a deal involving paper money you have on your person
> to your fellow passengers on the Titanic; that is the essence of your
> proposed bet hedging. Having studied the market for IPv4, it is a no-
> brainer to realise the driving force behind all these schemes. Delaying
> the inevitable is just going to make some people richer, to the detriment
> of others.  I see no reason to support that.

Howdy,

I can't tell if you believe what you just wrote or are trolling me
with satire. If it's satire... good one.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Thu, Nov 18, 2021 
at 01:46:04PM -0800 Quoting William Herrin (b...@herrin.us):
> 
> The detractors for this proposal and those like it make the core claim
> that we shouldn't take the long view improving IPv4 because IPv6 is
> going to replace it any day now. Each day that passes with the end of
> IPv4 still not in sight demonstrates how very wrong that strategy is.

Aw, come on. There is noone (except naive ones in power) who expect this
to happen immediately.  We all knew there would be a transition
period. The "improvement" part was CIDR. And a very good one it is at
that -- it sort of sets the standard as to what an improvement should
be to count. 6,25% new addresses from Net 240 is not an improvement in
that regard, and neither would the much smaller contribution from Net
127 be. Both are no more than holding paper money on the deck of the 
Titanic. 
 
The essence of an IP address is that it is unique. The larger the network
area is that recognizes it as unique, the better it is. That's why RFC
1918 is free and useless.  We all know this.

The only viable future is to convert.  This is not group-think, it is simple 
math. 

> If there's a change we can make to a standard now which will result in
> IPv4 being better 20 years from now, we should make it. We should hope
> that we never need the result because IPv6 takes over the world but we
> should make the change anyway. Because hedging our bets is what
> responsible people do.

You are proposing a deal involving paper money you have on your person
to your fellow passengers on the Titanic; that is the essence of your
proposed bet hedging. Having studied the market for IPv4, it is a no-
brainer to realise the driving force behind all these schemes. Delaying
the inevitable is just going to make some people richer, to the detriment 
of others.  I see no reason to support that. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
Yow!  It's a hole all the way to downtown Burbank!


signature.asc
Description: PGP signature

Re: Redploying most of 127/8 as unicast public

[Sean Donelan]

Time comes at you fast :-)

The POSIX committee has officially adopted 64-bit time_t as a requirement 
in the working draft of IEEE Std. 1003.1-202x and ISO/IEC 9945.


One thing to cross off my list. And I was looking forward to all the time 
machines crashing into the University of California Berkeley quad on

03:14:07 UTC on 19 January 2038.


On Wed, 17 Nov 2021, Sean Donelan wrote:

Other problems which will occur sooner:

1. Unix 32-bit time_t overflow.
2. North American Numbering Plan runs out of +1 zone phone numbers
3. IPv6 deployed and working everywhere/everything on the Internet
4. Analog AM and FM radio broadcasting deprecated (see digital DAB/DRM/HD)
5. Heat death of the universe

Re: Redploying most of 127/8 as unicast public

[bzs]

On November 18, 2021 at 11:15 c...@tzi.org (Carsten Bormann) wrote:
 > On 2021-11-18, at 00:29, Jay R. Ashworth  wrote:
 > > 
 > > This seems like a really bad idea
 > 
 > Right up there with the FUSSP.

They do have one thing in common which is people will immediately
shoot down proposals because they would take TEN (pick a number) YEARS
to make any difference.

And they'll continue saying that for 20+ years every time it comes up
absolutely certain each time that it's a showstopper.

My take is people reflexively don't like change, they tend to not like
others' solutions (the NIH reaction), and if they can get past those
they certainly want only a solution which can be deployed in a very
short period of time, likely to make a difference in a year or two if
not sooner, at no "cost".

Which is how we get things like yet another layer of encryption since
they're invariably voluntary (DO/DON'T, WILL/WON'T designs, default
DON'T), just cobbled into some existing protocol so can be deployed
immediately at least by a handful of supporters w/o any disruption or
urgency. At least those are failsafe, when almost no one adopts it who
cares?

(I realize there's no encryption involved here IT'S AN ANALOGY, a
meta-observation, OK?)

 > 
 > https://www.rhyolite.com/anti-spam/you-might-be.html
 > 
 > Someone should write a page like that about the FUSIAS (final ultimate 
 > solution to the IPv4 address shortage) proposals.
 > 
 > Grüße, Carsten
 >

I don't believe this is being proposed as a final...etc, just:

So long as we do have a shortage how might we at least not waste what
we do have so history doesn't laugh at us.

Let's engineer it to its inevitable depletion and not be even the
tiniest bit guilty of having exacerbated the runout in the vain and
futile hope that it might speed up IPv6 adoption.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Jim]

On Thu, Nov 18, 2021 at 11:05 AM John R. Levine  wrote:
..> The IETF is not the Network Police, and all IETF standards are entirely
> voluntary.

Yes, however the IETF standards can be an obstacle -- if they are, then
it is reasonable to adjust that which might impede a future useful development:
regardless of the fact that other obstacles may exist and it may be predicted
to be infeasible in the end.  The estimation that effort to update
software will not be
worthwhile much later (10 years from now)  cannot be made with enough
confidence;
the other efforts that need to happen is not justification to keep the
standard from changing so
that new/updated software coming out in the near future have a chance to
avoid making making future efforts to reclaim class E or a portion of
127/8 any harder than
they already are today.

The improbability or cost involved in getting software updated should
not impede updating a standard --  Just like the low rate of IPv6
deployment and the
estimation that IPv6 Never manage to fully and totally replace IPv4
should Not prevent
further development of IPv6  nor  giving up on IPv6, etc.

Both IPv4 and IPv6 are important standards that should continue to be
maintained.

> Nothing is keeping you from persuading people to change their software to
> treat class E addresses as routable other than the detail that the idea is

The standard could keep you from persuading people - if the standard
says that class E is something else, then the chance of it ever getting close
to be globally usable is about zero .

If the Standards are updated to say that it is globally routable,
Then the chance
of it ever becoming globally routable is still close to zero, at least
for a long period of time,
BUT at least it is improved,   even the small improvement that can
come from fewer new software programs
outright blocking it justifies updating the standard,  there is no
real downsideother than the time and effort'
to actually update the standards..


Adjusting 127/8  is the same way.  It seem pretty obvious this should be done..
make the reservation 127.0.0.0/24, or /32, even, and declare the full
of 127.0.0.0/8 as
Unicast reserved.  This does not immediately change any software or
operating systems nor
affect anyone's network, since the range in question is non-routable
it has only to do
with individual systems using IPv4 internally and privately,  not
related to the internet
or any IP networks to begin with  (unless some router internally have
a large swath
of 127/8 for internal system services on its main routing table) -  anyway,
System applications can continue using 127/8
internally on local loopback interfaces for local IPC to the heart's content,
Until such time as  Operating Systems choose to make (or choose not to
make) changes
to their own system networking functions and network libraries.

Or perhaps they would consider a configuration option such as
   -  "use one of the  /8s from Class E  for loopback, in Lieu of  127/8."


As a practical matter on modern OSes:  "127.*" seem more of a convenience;  You
can run network-based apps privately and use standard network tools such
as "telnet 127.0.0.0"  to test protocols over your local Loopback
'devices'  without needing
to  give an interface such as "ssh -B lo0 127.0.0.0"  --

If that's not the scenario  (Not a  need to access Local applications
using a common network utilities such
as 'ssh' or 'web browser'),   Then there are ample alternatives
for example:  "Open connection to file /opt/var/run/mysql.sock"
So, uh you only really have reason to use by design 127.0.0.0  if your
software wish to be used over a network.

If it's not such a "standard" client/server program being tested locally,
you can give an interface within the design of your local apps and use
Loopback networks all day without any 127 addresses..  if your OS
make you specify an interface instead of routing Loopback device
traffic,  then you could
potentially be allowed to accept and use Any IP in all of the IPv4
space on the Loopback
as part of a  separate and distinct private "network", so you could
Re-Use all the RFC1918
IP space for your Loopback IP space without conflicting with other
RFC1918 address usage.

You need only 1 IP address to talk to your local system -  Maybe you
run something such as Docker container host, I guess, then a whole /16
seem Ok...


> R's,
> John
--
-JH

Re: Redploying most of 127/8 as unicast public

[William Herrin]

On Thu, Nov 18, 2021 at 12:40 PM Fred Baker  wrote:
> I'm not sure what has changed in the past lotsa years other
> than which prefix people want to make essentially the same
> arguments about. My observation has been that people don't
> want to extend the life of IPv4 per se; people want to keep using
> it for another very short time interval and then blame someone
> else for the fact that the 32 bit integers are a finite set.

Hi Fred,

The detractors for this proposal and those like it make the core claim
that we shouldn't take the long view improving IPv4 because IPv6 is
going to replace it any day now. Each day that passes with the end of
IPv4 still not in sight demonstrates how very wrong that strategy is.

If there's a change we can make to a standard now which will result in
IPv4 being better 20 years from now, we should make it. We should hope
that we never need the result because IPv6 takes over the world but we
should make the change anyway. Because hedging our bets is what
responsible people do.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Fred Baker wrote:

I have read through this thread, and you'll pardon me if it sounds like yet 
another rehash on yet another list. You might take a look at 
https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/,
 which responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. 
I'm not sure what has changed in the past lotsa years other than which prefix 
people want to make essentially the same arguments about.


What has changed is that the intervening years have demonstrated that 
the proponents were right and the detractors were wrong. Very much so.



  My observation has been that people don't want to extend the life of IPv4 per 
se; people want to keep using it for another very short time interval and then 
blame someone else for the fact that the 32 bit integers are a finite set.



If you don't think that's a true statement, I'd be very interested to hear what 
you think might be true.

On this thread alone very thoughtful and knowledgeable sounding folk 
have made it quite clear that the efforts involved are a lot less and 
the potential benefits a lot more than the naysayers mantra.


Its time to update some assumptions.

Joe

Re: Redploying most of 127/8 as unicast public

[Fred Baker]

I have read through this thread, and you'll pardon me if it sounds like yet 
another rehash on yet another list. You might take a look at 
https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/,
 which responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. 
I'm not sure what has changed in the past lotsa years other than which prefix 
people want to make essentially the same arguments about. My observation has 
been that people don't want to extend the life of IPv4 per se; people want to 
keep using it for another very short time interval and then blame someone else 
for the fact that the 32 bit integers are a finite set. 

That strikes me as crazy. Put all of the remaining IPv4 prefixes (for some 
suitable definition of "remaining") in a bucket, decide that if they were all 
made unicast IP address space that would add  microfortnights to the 
life of the IPv4 Internet, and think about what happens next. Immediately, we 
all go back to sleep, fail to update our applications and deployments, and when 
that time interval has expired, we all whine about the stupidity of the IPv4 
designers that didn't not make IPv4 forward compatible with *any*thing* - the 
next step has to be a replacement - and try to figure out a way to represent 
more than 2^32 interfaces in a single 32 bit number 
(https://datatracker.ietf.org/doc/html/draft-terrell-math-ipaddr-ipv4) or 
redesign the Internet in some way that would require as much effort and money 
to deploy as IPv6 has since its inception. 

If you don't think that's a true statement, I'd be very interested to hear what 
you think might be true. 

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Justin Streiner]

The proposals I've seen all seem to deliver minimal benefit for the massive
lift (technical, administrative, political, etc) involved to keep IPv4
alive a little longer.

Makes about as much sense as trying to destabilize US currency by
counterfeiting pennies.

Thank you
jms



On Thu, Nov 18, 2021 at 12:39 PM Joe Maimon  wrote:

>
>
> John R. Levine wrote:
> >> The only effort involved on the IETF's jurisdiction was to stop
> >> squatting on 240/4 and perhaps maybe some other small pieces of IPv4
> >> that could possibly be better used elsewhere by others who may choose
> >> to do so.
> >
> > The IETF is not the Network Police, and all IETF standards are
> > entirely voluntary.
>
> And that is exactly why they said that even though they think it might
> possibly entail similar effort to deployment of IPv6 and that IPv6 is
> supposed to obsolete IPv4 before any such effort can be realized, they
> would be amenable to reclassifying 240/4 as anything other than
> reserved, removing that barrier from those whom may voluntarily decide
> to follow that updated standard, should they find the time to squeeze in
> another project the same size and effort of IPv6 into their spare time.
>
> Seems the IETF does indeed think it is the network police. And that they
> get to decide winners and losers.
> >
> > Nothing is keeping you from persuading people to change their software
> > to treat class E addresses as routable other than the detail that the
> > idea is silly.
> >
> > R's,
> > John
> >
>
> And indeed, they have done so. Now who looks silly?
>
> Joe
>
>

Re: Redploying most of 127/8 as unicast public

[William Herrin]

On Thu, Nov 18, 2021 at 10:14 AM Jay R. Ashworth  wrote:
> I could be wrong, but I don't think expanding 1918 was the goal of these
> proponents

Hi Jay,

I would be happy with the compromise where the addresses are assigned
to "unicast; reserved." We can fight over exactly what unicast use
they should be put to 20 years from now when ordinary equipment and
software churn has rendered the addresses more or less usable.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Redploying most of 127/8 as unicast public

[Jay R. Ashworth]

- Original Message -
> From: "Justin Keller" 

> I'd be fine if newish devices use it like a 1918 but I don't think
> it's worth the headache and difficulty of making it globally routed.
> Maybe  Amazon could use it too

I could be wrong, but I don't think expanding 1918 was the goal of these 
proponents

Cheers,
-- jra

> On Wed, Nov 17, 2021 at 6:31 PM Jay R. Ashworth  wrote:
>>
>> This seems like a really bad idea to me; am I really the only one who 
>> noticed?
>>
>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>>
>> That's over a week old and I don't see 3000 comments on it, so maybe it's 
>> just
>> me.  So many things are just me.
>>
>> [ Hat tip to Lauren Weinstein, whom I stole it from ]
>>
>> Cheers,
>> -- jra
>>
>> --
>> Jay R. Ashworth  Baylink   
>> j...@baylink.com
>> Designer The Things I Think   RFC 
>> 2100
>> Ashworth & Associates   http://www.bcp38.info
> > St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 
> > 1274

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Redploying most of 127/8 as unicast public

[John Kristoff]

On Thu, 18 Nov 2021 08:53:53 -0800
Jonathan Kalbfeld via NANOG  wrote:

> If we’re going to do something that Majorly Breaks the Internet(tm),
> why not talk about the 240/4 space instead?  

I like the proposal that suggest include a plan to reuse 224/4 (with
the exception of 224.0.0.0/24, but it looks like the plan is OK with
not using any of 224.0.0.0/8). With apologies to our small set of
friends who are keeping the interdomain dream alive, I might help
advocate for such a plan not because of what it adds, but because
of what it helps hasten the demise of.  :-)

John

Re: WKBI #586, Redploying most of 127/8 as unicast public

[David Conrad]

On Nov 18, 2021, at 9:00 AM, John R. Levine  wrote:
>> The only effort involved on the IETF's jurisdiction was to stop squatting on 
>> 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly 
>> be better used elsewhere by others who may choose to do so.
> 
> The IETF is not the Network Police, and all IETF standards are entirely 
> voluntary.

True…

> Nothing is keeping you from persuading people to change their software to 
> treat class E addresses as routable other than the detail that the idea is 
> silly.

Of course, it’s not quite that simple.

First, 
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml 
 
would need to be updated, then the RIRs would need to issue a request according 
to https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en 
. At 
that point, existing requests lodged at the RIRs could be fulfilled using the 
formerly reserved space. Network operators that received the allocations could 
then number their devices with the new address space and announcing that space 
into the routing system.

Of course, there are probably an unknowable number of “bogon” filters out there 
that are hardcoded into various bits of infrastructure that would need to be 
updated. There are also various hardware, firmware, and software IP stack 
implementations, perhaps sitting in closets somewhere, that still think they 
can’t use reserved space that would need to be updated/replaced.

As far as I can tell, assertions about the scale of that update/replace 
exercise are based on limited data. Perhaps as an alternative to declaring 
various chunks of reserved space as free for use, a chunk of that space could 
be allocated to one or more of the RIRs and announced with a set of services 
placed upon it to see just how much actually breaks, similar to what APNIC and 
Cloudflare did with 1.1.1.0/24?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

Jonathan Kalbfeld via NANOG wrote:
How much runway would a single /8 give us? 
Up to 65280 /24's becoming available through registrars would be quite 
welcome to lots of small organizations or startups.



 Is it worth the headache to gain a single /8 ?


I support serious consideration be given to determine the extent of the 
headache and to answer that question.




If we’re going to do something that Majorly Breaks the Internet(tm), 
why not talk about the 240/4 space instead?


I think 240/4 is indeed a very good idea deserving of proper 
consideration. That does not mean that other ideas arent worthy as well.


But at this point 240/4 is practically a no brainer.



We can’t fight address exhaustion on the supply side.  The 
only way to fix IPv4 exhaustion is by shifting the demand curve inward 
and that is through IPV6 and aggressive reclamation of IPv4 
space.


Jonathan

Jonathan Kalbfeld

office: +1 310 317 7933 
fax: +1 310 317 7901 
home: +1 310 317 7909 
mobile: +1 310 227 1662 

ThoughtWave Technologies, Inc.
Studio City, CA 91604
https://thoughtwave.com

View our network at
https://bgp.he.net/AS54380

+1 213 984 1000

On Nov 17, 2021, at 3:29 PM, Jay R. Ashworth > wrote:


This seems like a really bad idea to me; am I really the only one who 
noticed?


https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

That's over a week old and I don't see 3000 comments on it, so maybe 
it's just

me.  So many things are just me.

[ Hat tip to Lauren Weinstein, whom I stole it from ]

Cheers,
-- jra

--
Jay R. Ashworth  Baylink 
  j...@baylink.com
Designer The Things I Think 
  RFC 2100

Ashworth & Associates   http://www.bcp38.info
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 
647 1274

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Joe Maimon]

John R. Levine wrote:
The only effort involved on the IETF's jurisdiction was to stop 
squatting on 240/4 and perhaps maybe some other small pieces of IPv4 
that could possibly be better used elsewhere by others who may choose 
to do so.


The IETF is not the Network Police, and all IETF standards are 
entirely voluntary.


And that is exactly why they said that even though they think it might 
possibly entail similar effort to deployment of IPv6 and that IPv6 is 
supposed to obsolete IPv4 before any such effort can be realized, they 
would be amenable to reclassifying 240/4 as anything other than 
reserved, removing that barrier from those whom may voluntarily decide 
to follow that updated standard, should they find the time to squeeze in 
another project the same size and effort of IPv6 into their spare time.


Seems the IETF does indeed think it is the network police. And that they 
get to decide winners and losers.


Nothing is keeping you from persuading people to change their software 
to treat class E addresses as routable other than the detail that the 
idea is silly.


R's,
John



And indeed, they have done so. Now who looks silly?

Joe

Re: WKBI #586, Redploying most of 127/8 as unicast public

[John R. Levine]

The only effort involved on the IETF's jurisdiction was to stop squatting on 
240/4 and perhaps maybe some other small pieces of IPv4 that could possibly 
be better used elsewhere by others who may choose to do so.


The IETF is not the Network Police, and all IETF standards are entirely 
voluntary.


Nothing is keeping you from persuading people to change their software to 
treat class E addresses as routable other than the detail that the idea is 
silly.


R's,
John

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Joe Maimon]

Dave Taht wrote:
I am sad to see the most controversial of the proposals (127/16)  > first discussed here. > > Try this instead? > > 
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ 
> > >

in my mind, has the most promise for making the internet better in the
nearer term.  > > Could I get y'all to put aside the 127 proposal and read that 

over, > instead?

/30 now becomes 2 usable IP addresses for the customer.

/29 "5 static IP addresses" now becomes 6?

Doing vrrp for a customer /29 gets a bit easier.


> > ... > > It's ok, I'll wait... > > ... > > There were two other 
proposals concerning 240/4 and 0/8 also worth > reading for their 
research detail and attention to history.


Good thing they werent worried about wasting the IETF's valuable and 
precious time running the internet, because the masses cant possibly be 
trusted.


> The amount of work required to make 240/4 work in most places is now 
> very close to zero, having been essentially completed a decade ago. > 
240/4 and 0/8 checking is not present in the SDN codes we tried, and > 
we ripped the 0/8 check out of linux 3? 4? years back. Saves a few > ns. 
> > All but one iOt stack we tried worked with these, many of those > 
stacks still lack, or have poor ipv6 support. esp32 anyone? > > Just as 
ipv6 today is not globally reachable, these address spaces > may never 
be globally reachable, but defining a standard for their > potential 
sub-uses seems like a viable idea. > >


On the face of it, any of the above statements should be enough to 
silence and shameface any and all of the historical naysayers.


However it would appear they are still living in the past, as evidenced 
by continued citing of "pre-exhaustion burn rate" as if the excesses of 
the past are somehow relevant to the consumption of the future other 
than an indictment of non-prudence.


Joe

Re: Redploying most of 127/8 as unicast public

[Jonathan Kalbfeld via NANOG]

How much runway would a single /8 give us?  Is it worth the headache to gain a 
single /8 ?

If we’re going to do something that Majorly Breaks the Internet(tm), why not 
talk about the 240/4 space instead?  

We can’t fight address exhaustion on the supply side.  The only way 
to fix IPv4 exhaustion is by shifting the demand curve inward and that is 
through IPV6 and aggressive reclamation of IPv4 space.

Jonathan

Jonathan Kalbfeld

office: +1 310 317 7933 
fax:+1 310 317 7901 
home:   +1 310 317 7909 
mobile: +1 310 227 1662 

ThoughtWave Technologies, Inc.
Studio City, CA 91604
https://thoughtwave.com 

View our network at 
https://bgp.he.net/AS54380 

+1 213 984 1000

> On Nov 17, 2021, at 3:29 PM, Jay R. Ashworth  wrote:
> 
> This seems like a really bad idea to me; am I really the only one who noticed?
> 
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
> 
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me.  So many things are just me.
> 
> [ Hat tip to Lauren Weinstein, whom I stole it from ]
> 
> Cheers,
> -- jra
> 
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates   http://www.bcp38.info  
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Joe Maimon]

Mark Andrews wrote:
CIDR is much older than that and we still have to avoid .0 and .255 
addresses in class C space. 


I use .0 all the time.

Similarly for .0.0 and .255.255 for class B space and .0.0.0 and 
.255.255.255 for class A space. Getting everybody you want to contact 
and the path in between to be clean for 240/4 is more than just a 
replacement cycle. There is a lot of really old gear out there that 
still talks to the world and it will never work with 240/4 addresses. 
If you are selling IPv4 connectivity and your customer is given a 
240/4 address but can’t reach some place on the internet that their 
neighbour with out a 240/4 can who are they going to blame? Can you 
afford the defective product law suite. You gave then an address that 
you knew fore well would not work reliably with the Internet as a 
whole. Using 1/8 is still fraught. At least with 1/8 you are not 
fighting kernels that need to be modified for which source is not 
available. 


No address comes with any guarantees. Suppose you are 100% correct. Its 
not the IETF's role to manage the community at large resource 
expenditures, whatever their opinion may be.


The only effort involved on the IETF's jurisdiction was to stop 
squatting on 240/4 and perhaps maybe some other small pieces of IPv4 
that could possibly be better used elsewhere by others who may choose to 
do so.


Joe

Re: Redploying most of 127/8 as unicast public

[Justin Keller]

I'd be fine if newish devices use it like a 1918 but I don't think
it's worth the headache and difficulty of making it globally routed.
Maybe  Amazon could use it too

On Wed, Nov 17, 2021 at 6:31 PM Jay R. Ashworth  wrote:
>
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me.  So many things are just me.
>
> [ Hat tip to Lauren Weinstein, whom I stole it from ]
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates   http://www.bcp38.info
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Dave Taht]

I am sad to see the most controversial of the proposals (127/16) first
discussed here.

Try this instead?

https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/

in my mind, has the most promise for making the internet better in the
nearer term.

Could I get y'all to put aside the 127 proposal and read that over, instead?

...

It's ok, I'll wait...

...

There were two other proposals concerning 240/4 and 0/8 also worth
reading for their research detail and attention to history.

The amount of work required to make 240/4 work in most places is now
very close to zero, having been essentially completed a decade ago.
240/4 and 0/8 checking is not present in the SDN codes we tried, and
we ripped the 0/8 check out of linux 3? 4? years back. Saves a few ns.

All but one iOt stack we tried worked with these, many of those stacks
still lack, or have poor ipv6 support. esp32 anyone?

Just as ipv6 today is not globally reachable, these address spaces may
never be globally reachable, but defining a standard for their
potential sub-uses
seems like a viable idea.