Redploying most of 127/8 as unicast public

Mailman List Mirror (Read Only)
181

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)

182

Owen DeLong wrote:

The number of routing table entries is growing exponentially, not
because of increase of the number of ISPs, but because of multihoming.

Again, wrong. The number is growing exponentially primarily because
of the fragmentation that comes from recycling addresses.

Such fragmentation only occurs when address ranges are rent to
others for multihoming but later recycled for internal use,
which means it is caused by multihoming.

Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a class A
as smaller prefixes to various other purchasers.

It happens when /16s are sold off to multiple purchasers in pieces.

Anyway, such cases are quite unlikely and negligible.

ROFLMAO you are demonstrating your extreme detachment from reality:

http://ipv4marketgroup.com
http://ipv4auctions.com
etc.

There are multiple businesses that do almost nothing outside of these types of transactions.

There are actually ways to do IPv6 multihoming that don’t require
using the same prefix with both providers.

That’s what I proposed 20 years ago both with IPv4 and IPv6 in:

https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

THat’s not one of the alternatives I was talking about.

Yes, there are tradeoffs,
but these mechanisms aren’t even practical in IPv4,

Wrong. As is specified by rfc2821:

When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable

the idea of end to end multihoming is widely deployed by SMTP at
the application layer, though wider deployment require TCP
modification as I wrote in my draft.

Again, NOT what I was talking about. I was talking about the fact that in IPv6, you can multi-home by applying a prefix from each provider to each subnet. If the upstream connection goes away, deprecate the RA for that prefix and/or mark it as no longer on-link.

Similar specification is also found in section 7.2 of rfc1035.

You are talking about pomegranate seeds, I’m talking about Apples. They are not the same, so your statements about my remarks are inherently flawed.

but have been
sufficiently widely implemented in IPv6 to say that they are viable
in some cases.

You are just wrong. IP layer has very little to do with it.

No, you’re just talking about a form of multihoming that has absolutely nothing to do with the forms I was referring to.

LISP is garbage.

Somewhat agree, though the concept wasn’t entirely wrong. Separating Locators from IDs is something we will eventually need to do in order to scale internet routing. LISP is definitely
not the ideal way to do it, but was a valiant attempt if one assumes the constraints of having to operate in an existing IPv6 environment. If one is willing to modify the packet header, then there are better options.

Owen

183

It appears that Francis Booth via NANOG <boothf@boothlabs.me> 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

184

When considering the IPv6 product, I would suggest you read USGv6-Revision-1 (1) to define the specification you need for the product. Then go to the USGv6 Registry (2), select the features and read the Supplier Declaration of Conformity (SDOC) to ensure that the product meets your requirements. Do this prior to having the discussion with the vendor sales.

Also, ask for documents which provide details on performance and security testing. It will save you hours of troubleshooting problems and patching vulnerability.

Lessons learned from implementing IPv6 products.

(1) https://www.nist.gov/programs-projects/usgv6-program/usgv6-revision-1
(2) https://www.iol.unh.edu/registry/usgv6

185

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

186

> 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

187

Dave Taht wrote:

The proper solution is to have end to end multihoming:

         https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

I'd never read that. We'd made openwrt in particular use "source
specific routing" for ipv6 by default,
many years ago, but I don't know to what extent that facility is used.

Considering that most, if not all, multihomed sites should have
rich (maybe full) routing table in some part (at least) of the
sites between exit routers to balance load between the routers,
I can't see why source specific routing was considered necessary
only to cause routing loops.

For multihoming with PA address ranges with plain TCP/UDP,
what is necessary for ISP failure is to have routing
protocols to carry proper source address ranges for each
routing table entry and to modify end systems to listen to
routing protocol and choose proper source address, which
is against the poor architecture of IPv6/ND to assume
intelligent routers and dumb hosts.

But, even with that, if some ISP fails, TCP/UDP through
the ISP will fail and must be restarted with new source
address, which is not very useful. Moreover, if destination
is also inside another multihomed site with PA address ranges,
all the destination addresses must be tried.

So, as modifying end systems is inevitable, there is
no reason not to support full end to end multihoming
including modifications to support multiple addresses
by TCP and some applications.

          Masataka Ohta

188

Owen DeLong wrote:

Again, wrong. The number is growing exponentially primarily
because of the fragmentation that comes from recycling
addresses.

Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a
class A as smaller prefixes to various other purchasers.

That, by no means, is not recycling. Moreover, most, if not
all, entities purchasing address ranges use them with multihoming.

> ROFLMAO you are demonstrating your extreme detachment from reality:

So, you have never thought about the reason why people buy
IP addresses.

>> https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt
>
> THat's not one of the alternatives I was talking about.

That you haven't mentioned any alternative and have talked
about nothing is your problem.

            Masataka Ohta

189

Are you proposing SCTP? There is sadly not much more hope for widespread adoption of that as of IPv6.

Regards,

Baldur

190

If you use Apple, you use MP-TCP, for better UX while using both
mobile and wifi.

SCTP is no good, because you cannot transition between two
connections, they have to overlap for a period, there is no separation
of identity and location. QUIC actually can do that, in that identity
is PKI and location is IP address, so you could roam from one IP to
another IP without having overlapping connectivity.

191

or perhaps MP-TCP? :slight_smile: or shim6?

192

Shim6 died a comprehensive death many yers ago. I recall NANOG played a role in it's untimely demise. :slight_smile:

Geoff

193

oh, darn! :slight_smile:

reading the ID that masataka referenced, it sounded very much like shim6 about ~4 yrs prior to shim6’s “invention”.
I also don’t recall seeing the draft referenced during the shim6 conversations.

Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows… nor IPSEC nor GRE nor…
unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!

Talk about layer violations! talk about fun!

-chris

194

Bill,

  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.

  1. 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.

  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

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

195

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

196

Baldur Norddahl wrote:

Are you proposing SCTP? There is sadly not much more hope for widespread
adoption of that as of IPv6.

My ID describes the architectural framework both for IPv4 and IPv6.

Modification to TCP is discussed, for example, in:

  draft-arifumi-tcp-mh-00

I still think something like that is necessary before IPv4 global
routing table size become 16M (ignoring loopback/multicast/ClassE).

Christopher Morrow wrote:

> reading the ID that masataka referenced, it sounded very much like
> shim6 about ~4 yrs prior to shim6's "invention".

No, not at all.

> I also don't recall
> seeing the draft referenced during the shim6 conversations.

Despite my ID saying:

    All the other processing can be
    performed by transport layer (typically in kernel) using
    default or application specific timing of TCP.

    Without TCP, applications must be able to detect loss of
    connectivity in application dependent way

shim6 is wrongly architected to address the issue at the
*connectionless* IP layer, where there is no proper period
for timeout. Also, transport/application layer information
such as TCP sequence numbers may offer proper security.

Notion of connection (including half one such as DNS
query/reply at the application layer) is essential
for proper state maintenance.

Similar layering violation also occurred to network
layer PMTUD, which is why it is rather harmful than
useful.

            Masataka Ohta

197

I can tell you it's observable out there and if i use my home network
to follow default i can tell it is working through those devices at
least.

I agree with Randy it would be good if someone did this, it shouldn't be
too hard with ripe atlas and a provider deciding to announce something
like 240.2.3.0/24 to see if it can be reached.

  That's at least a decent measurement and report, but the client
side OS will still be a variable that is difficult to digest. Not sure
how many people are running very old IP stacks. This is another hard to
measure problem.

  - Jared

198

>
> > these measurements would be great if there could be a full research-
> > style paper, with methodology artifacts, and reproducible results.
> > otherwise it disappears in the gossip stream of mailimg lists.
> >
> Maybe an experimental rfc making it a rfc 1918-like subnet and implementing
> it on openwrt or something like that to see what happens. how many ip
> cameras and the like roll over and die? same for class E addresses too, I
> suppose. The question with anything that asks about legacy is how long the
> long tail actually is.
>
> Mike, not that have any position on whether this is a good idea or not

        I can tell you it's observable out there and if i use my home network
to follow default i can tell it is working through those devices at
least.

I agree with Randy it would be good if someone did this, it shouldn't be
too hard with ripe atlas and a provider deciding to announce something

the atlas is good stuff, I am curious (OT) if they have added a
videoconferencing-like test to it?

like 240.2.3.0/24 to see if it can be reached.

I very much would like a study of 240/4. In particular, announcing
255.255/16 might pick up a lot
of misconfigured routers out there.

Tests of the DNS would also be useful. This test setup has been
working for years now...

$ host postel.taht.net
postel.taht.net has address 85.90.246.167
postel.taht.net has address 255.255.255.254 # wireguard vpn presently
postel.taht.net has address 0.0.0.1 # wireguard vpn
postel.taht.net has IPv6 address 2a01:7e01:e001:28:f3ee:d002:0:beef #
ironically the ipv6 address is down and I hadn't noticed!

199

Christopher Morrow <morrowc.lists@gmail.com> writes:

Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows...
nor IPSEC nor GRE nor...
unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that!

IP over DNS has been a thing forever. IP over DoH should work just
fine.

Talk about layer violations! talk about fun!

Yes, fun...

Bjørn

200

Feh. I've written transistors over http. Beat that.

Mike