I am concerned about fragmentation of the net, but in ways that seem to be divergent than the concerns I usually hear.

Many, probably most, of us Internet grey beards think of "the Internet" in terms of the end-to-end principal of IP (v4 or v6) packets moving without much hindrance from a source network interface with an global/public IP address to another network interface with its own global/public IP address.

I think that world is dead.

NATs put a nail into the end-to-end principle, but a nail that actually helped us expand the IPv4 net without too much damage (except to some old protocols, such as FTP, that carry IP addresses as data - most modern protocols are reasonably amenable to NATs and TCP-concatenating proxies.)

But there is a different way of looking at The Internet that is not based on the old packet-based end-to-end principle.  That way is to look at The Internet as a collection of underlying internets (lower case) of various technologies and addressing that are connected together so that favored (there is much danger in that word "favored" - I'll get to that in a moment) applications work between users.

This is really saying that we have turned the wheel once more in our long progression from "networks" (e.g. ARPAnet) to "network of networks" (Postel's "Internet") and now a "network of networks of networks" - a world in which "end-to-end" refers not to packets but to application inter-operation.

(This idea is the underlying theme of my somewhat long blog item from 2016: "Internet: Quo Vadis (Where are you going?"  at https://www.cavebear.com/cavebear-blog/internet_quo_vadis/  That note envisioned an evolution - one that I believe is happening - in which the once unified Internet changes into a system of highly protected "islands" [such as a Google island, a Facebook island, a China island, various fundamentalist religious islands, etc] that are interconnected by guarded, taxed, filtered, and inspected bridges.  This is not unlike the walled cities of medieval Europe where the gates in the walls were used as much for taxation and excluding undesirables and foreigners as they were for defense in war.)

I mentioned that there is danger - that danger is that these inter-island bridges will be open only to the most popular of applications.  To use a modern example, this future Internet-of-internets, might allow protocols such as Twitter or Facebook but might exclude new ideas such as Activity Pub (used by things like Mastodon.)  In other words, our notion of "innovation at the edge" will not necessary be valid across this global Internet-of-internets.

I have concerns about this future that I see.  But those concerns are not necessarily fears as much as concessions to the reality that despite our protestations, we humans tend to form clumps - tribes, nations, corporations, religions - and we seem to like having the means to pull up the drawbridges, in full or in part, that connect us with others.  In addition, security concerns, intellectual property concerns, and the like are pushing in that direction - note recent legal developments around the world to impose content restrictions or require proof-of-age or proof-of-identity.  Or there may be content restrictions, for instance music that is still under copyright in the US may be in the public domain elsewhere.

The early Internet grew out of the one-world ideas of the hippie culture of the late 1960s - I know, I was there.  But rather than tearing down borders, the Internet is drawing more boundaries and making the old ones more complicated.

        --karl--

Thanks Karl,

 

not totally new, but very helpful in the new environment of the 2020s.

 

Isn´t this a more serious threat to "Internet Fragmentation" than govermental efforts to introduce "national sovereignty" (on the application layer) into the borderless cyberspace?

 

And "Happy Holidays"!!

 

Wolfgang

 

 

Karl Auerbach via At-Large <at-large@atlarge-lists.icann.org> hat am 21.12.2023 20:31 CET geschrieben:

 

 

You make good points.

 

I have long accepted the concept of competing root systems and have

suggested various ways in which they could co-exist without causing

discomfort for users, particularly with regard to collisions between

divergent versions of the same TLD string. (See my year 1999 note:

https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#multiple_roots )

 

As you mention, we most definitely have some strong neo-root (as opposed

to fully distinct competing root) systems, such as Google's 8.8.8.8,

Comcast's 75.75.75.75, Cloudflare's 1.1.1.1, etc (and their IPv6

equivalents.)  Whether the query streams to these are being data mined

is unknown to me. However, I doubt that in today's world of "shareholder

value" that commercial companies, particularly those who strongly

leverage their revenue streams from personal network usage data they

gather, will long resist the temptation to monetize those query streams

- indeed I would be surprised if some have not done so already.  One may

ask, as I will do here: Why are these for-profit companies spending

not-inconsequential amounts of money to deploy services that are

redundant with the legacy root system?  We would be naive to think that

these for-profit companies will long expend shareholder owned assets

without expectation of some compensating business advantage or revenue

stream.

 

The legacy root server system has one characteristic that we too often

overlook: It is run at an extremely high level of professionalism.  It

is so high that there is usually no incentive to look to any other offering.

 

And that professionalism has little to do with ICANN.

 

For instance, remember the limitation (caused by the way that names are

encoded into 512 byte UDP DNS packets) that places a limit of about 13

root name servers?  Remember the contention that that caused in the

early days of ICANN because those 13 places were not equitably

distributed around the world?  It was not ICANN that came up with the

notion of anycast groups of name servers, rather it was the external

community that created the idea and it was the root server operators who

went forth and did the work to make it happen - they did not give ICANN

notice of this, nor await ICANN permission, nor did they ask for ICANN

funding - they just did it.  And as a result, the net is a better place.

 

DNS technology is not the perfect answer to all questions - I've written

about how DNS is insufficient to support the naming needs of net based

distributed applications that move, split, and merge like blobs in a

lava lamp.  E.g. My 2010 note "On Entity Associations In A Cloud

Network" https://www.cavebear.com/archive/public/cloud-entities.pdf

 

And I see some well intentioned efforts that are trying to push DNS for

uses that it is not necessarily appropriate or in ways that could create

unnecessary risks of code flaws that could lead to attacks or security

vulnerabilities (this is especially true in the Internet-of-Things world

where code is often weak and relies on use in a confined, non-stressful

network environment.  For example, should the coming generation of

TCP/IP based Engine Control Units [ECU] in a vehicle have to implement

Punycode and UTF-8 or ought they take the safer path of simply rejecting

any non-ASCII names?)

 

        --karl--

 

On 12/21/23 3:34 AM, Christian de Larrinaga via At-Large wrote:

I suspect it may well be too late (20 years too late!) to use the

"reserve for posterity" approach for namespaces. A call to do this would

no doubt be taken up at WIPO not ICANN anyway given the long standing

issue with ICANN surrendering names as solely for business and

governmental utility over its designed use for edge to edge resolution

services. That would further push DNS away from the Internet edge and so

itself be destabilising.

 

There's also a question whether the single root argument made by IAB

in 2000 is still gospel in a world where e2e offers secure

frameworks for attestations of an infinite variety of namespaces and

identifiers than is even conceivable for the DNS infrastructure.

 

Particularly as DNS resolution is interpretative (punycode etc) today

and largely anycast with geographical routing depending source and

destination addressing which in turn depend on unofficial geo IP

databases which are far from dependable given the growth in over and

under private networks using their own choice of gateways into the

"Internet". I am almost never in the place "The Internet" tells me I am

in!

 

But I take your insider political perspective on the ICANN

firmament. But it rather confirms my concern that ICANN has been far to

comfortable with the DNS industry as a private club believing everybody

has to go through the DNS that it "controls".

 

The reality is ICANN does not control the DNS just access to the root

server resolution system. That is implemented as a tax and unsurprising

if users think differently

 

C

 

 

Alejandro Pisanty via At-Large <at-large@atlarge-lists.icann.org> writes:

 

1. ( ) text/plain (*) text/html

 

Matthias,

 

thanks very much for this rich information. The summaries alone should be considered as strong alarm signs. The

foci of attention of ALAC and At-Large seem way out of phase, lagging years behind these developments. This is

not uniform; some RALOs are in even worse shape, considering recent publicly available evidence.

 

Alejandro Pisanty

 

On Thu, Dec 21, 2023 at 12:21 AM Matthias M. Hudobnik via At-Large <at-large@atlarge-lists.icann.org> wrote:

 

Hi colleagues, the SSAC has published SAC123 and SAC122.

 

 

 

 

 

### SSAC Report on the Evolution of Internet Name Resolution (SAC123):

 

· Internet name resolution is evolving beyond just the global DNS to include alternative naming systems

that are experimenting with different approaches for reasons like speed, privacy, censorship resistance, and

governance.

 

· Many alternative systems adopt DNS name syntax to leverage existing software.

 

· Two concerning trends are increased ambiguity where the same name can resolve differently in

different systems, and less visibility of names to end users even as names remain vital for security and trust.

 

· Maintaining integrity and coordination in the shared domain namespace is important.

 

· The report explores different perspectives on these trends from end users and developers.

 

· It identifies proposals to facilitate namespace coordination and recommends ICANN continue tracking

these issues and provide regular updates to the community.

 

I highly recommend having a look at chapter: 7.1 End Users (some key aspects as follows):

 

· Domain names used to play an important role for end users in discovering web resources, but search

engines have now replaced them as the primary method of discovery.

 

· End users today rarely directly interact with domain names due to the dominance of search engines and

mobile devices. Features like browser "omnibars" also allow more free-form input.

 

· Other identifiers like QR codes and social media handles now also compete for users' attention rather

than domain names.

 

· Domain names are becoming less visible in users' environments, yet they still provide an underlying

ubiquitous resolution context relied upon by other technologies.

 

· Surveys found search engines are by far the predominant method for accessing websites, with domain

name usage declining. QR code usage is increasing but still limited except in Asia.

 

· Decreased domain name visibility makes it easier for fraudsters to deceive users with lookalike names.

Users are also generally unaware that some TLDs signal a different resolution context.

 

In summary, domain names are no longer the primary method end users employ to find and access Internet

resources, decreasing their visibility and understandability while introducing security issues.

 

 

 

Link to the report:

https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-123-15-12-2023-en.pdf

 

 

 

 

 

 

### SSAC Report on Urgent Requests in gTLD Registration Data Policy (SAC122)

 

· Focus is on handling of Urgent Requests in proposed gTLD registration data policy

 

· Urgent Requests refer to imminent threats to life, injury, infrastructure or child exploitation

 

· Proposed policy requires response to Urgent Requests in 24 hours generally

 

· SSAC contends proposed policy for Urgent Requests is not fit for purpose

 

· Definition and required response times are incompatible

 

· Questions if need and rationale for separate Urgent Request process is fully justified

 

· Existing ICANN policy and industry practices offer useful precedents

 

· Proposed extensions allow responses up to 7 days, not reflecting urgency

 

· Lack of concrete data on frequency and handling of such requests currently

 

· Risks reputation of ICANN multistakeholder model effectiveness

 

- Provides 3 recommendations

 

§ Add structure to ensure Urgent Requests handled expediently

 

§ Tighten response time requirements to be fit for purpose

 

§ Gather data on Urgent Requests for future policy making

 

Link to the report:

https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-122-12-12-2023-en.pdf

 

 

 

 

Have a nice evening!

 

Best,

 

M.

 

 

 

______________________________

 

Ing. Mag. Matthias M. Hudobnik

 

FIP • CIPP/E • CIPT • DPO • CIS LA

 

matthias@hudobnik.at

 

http://www.hudobnik.at

 

@mhudobnik

 

_______________________________________________

At-Large mailing list

At-Large@atlarge-lists.icann.org

https://atlarge-lists.icann.org/mailman/listinfo/at-large

 

At-Large Official Site: http://atlarge.icann.org

_______________________________________________

By submitting your personal data, you consent to the processing of your personal data for purposes of

subscribing to this mailing list accordance with the ICANN Privacy Policy

(https://www.icann.org/privacy/policy) and the website Terms of Service

(https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status

or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g.,

for a vacation), and so on.

 

_______________________________________________

At-Large mailing list

At-Large@atlarge-lists.icann.org

https://atlarge-lists.icann.org/mailman/listinfo/at-large

 

At-Large Official Site: http://atlarge.icann.org

_______________________________________________

By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.