Subject: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

From: Dirk Trossen <[email-masked]>
Date: Wed, 1 Dec 2021 08:52:20 +0000

Dear all,

Many thanks for those participating in the side meeting on Internet addressing during the IETF 112 week. As suggested during the meeting, we want to take various points of discussion during the meeting onto the mailing list to continue discussion here on possible ways forward.

Specifically, we wanted to come back on the issue that a larger architectural discussion may be needed, a point that we make towards the end of the GA draft (https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/), but which was also core to Dirk K's main point that only such architecture discussion may lead to possibly needed changes to addressing. We will be looking into such possibly larger discussion along different possible avenues.

For our discussion here on the INT area list, we found Dino's related suggestion particularly useful in that we may need a discussion on what we (as users) may want from a network. We feel that our current GA draft may contribute to this question by observing that the many extensions to Internet addressing that we have gathered so far may be seen as an expression of a desired feature that those proposing the extension may want to see from the network. Hence, in addition to positioning those extensions as identified gaps to Internet addressing, we may want to formulate those extensions as desired features towards an extended Internet system, not just addressing; this can be done through suitably extending the GA draft with another section.

Why is this useful? We think that such view provides an observational input into the question that Dino suggests to answer, which in turn links to the larger architectural discussion that Dirk K suggests to have. While the overall architectural discussion may (and likely will) touch on more than 'just' addressing, we as a community may contribute to the discussion by rationalizing the work that has been done in this space.

We would like to solicit thoughts on this proposed way forward as concrete steps for the community here on the list. Also, anybody wanting to provide concrete input and contribution to this proposed revision of the draft is more than welcome.

Best,

Dirk
(on behalf of the co-authors)

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 1 Dec 2021 14:18:06 -0800

Here's my single feature request the network layer should provide:

(1) I want to be connected ALL THE TIME, I want my computer to use all its links, either cabled or radio, ALL THE TIME.

(2) I do not want to turn on and off wifi to get my device/computer to connect when it is currently not connected. The network layer should do all this for me.

(3) I want it easy for people to find me (my IP address), so I don't want multiple addresses from the user level. I want one device ID, EID, host address, whatever you want to call it. I want you to "ping <dino's-computer>".

Yes, I want host multi-homing and mobility. And I want it to work seamlessly.

Speaking as a user,
Dino

> On Dec 1, 2021, at 12:52 AM, Dirk Trossen <dirk.trossen=[email-masked]> wrote:
> 
> Dear all,
>  
> Specifically, we wanted to come back on the issue that a larger architectural discussion may be needed, a point that we make towards the end of the GA draft (https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/), but which was also core to Dirk K’s main point that only such architecture discussion may lead to possibly needed changes to addressing. We will be looking into such possibly larger discussion along different possible avenues.
>  
> For our discussion here on the INT area list, we found Dino’s related suggestion particularly useful in that we may need a discussion on what we (as users) may want from a network. We feel that our current GA draft may contribute to this question by observing that the many extensions to Internet addressing that we have gathered so far may be seen as an expression of a desired feature that those proposing the extension may want to see from the network. Hence, in addition to positioning those extensions as identified gaps to Internet addressing, we may want to formulate those extensions as desired features towards an extended Internet system, not just addressing; this can be done through suitably extending the GA draft with another section.
>  
> Why is this useful? We think that such view provides an observational input into the question that Dino suggests to answer, which in turn links to the larger architectural discussion that Dirk K suggests to have. While the overall architectural discussion may (and likely will) touch on more than ‘just’ addressing, we as a community may contribute to the discussion by rationalizing the work that has been done in this space.
>  
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 2 Dec 2021 08:31:25 +0000

Hi Dino,

Many thanks for the reply. Let me tie this back to my question regarding the draft: would you think it being a useful exercise to link the extensions described in the GA draft with those desired features from a user perspective? Would you be able/willing/happy to contribute to this?

More inline.

Best,

Dirk

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: 01 December 2021 23:18
To: Dirk Trossen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Yes, I want host multi-homing and mobility. And I want it to work seamlessly.
[DOT] As a user, do I *really* care about "my computer"? What does my computer signify? I have a number of those (computers), I have diversity in that certain devices do certain things (and certain things they don't) in terms of things I may care about. ICN asked that question many years ago: is the WHERE that matters or the WHAT? Do I want my computer to sit at the endpoint of communication or my service (or information), meaning does network layer communication identify the computer or its computational element (which may be replicated in a number of network locations)? 

[DOT] DNS+IP may be the quick technical answer to my last question but that brings me to another user perspective, namely that of constraints to the basic idea of exposing my services/information to the network. I may want constraints on availability (which may lead to "ALL THE TIME" being connected, or not), timing, dynamicity, privacy, security, but also efficiency (since I may care about costs but I may also care about "greenness" of the communication). Those constraints may be quite different for different users (my mother does not care about ALL THE TIME at all, but cares about receiving information on tablet and mobile device at the same time, while using her networked desktop for nothing messaging related at all) but also for different services. 

[DOT] I think Fred's "6Ms" of networking come into play when answering the constraint-based user requirements from a technical standpoint. 

Speaking as a user,
[DOT] Trying to answer as one.
Dino

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 2 Dec 2021 11:44:43 +0000

The key question that I would ask Dino is whether these need to be addressed at the network layer?

> On 1 Dec 2021, at 22:18, Dino Farinacci <[email-masked]> wrote:
> 

It can do this by treating these as independent links with different addresses and bind them in the application or through some OS service.

> (2) I do not want to turn on and off wifi to get my device/computer to connect when it is currently not connected. The network layer should do all this for me.

Is that a network layer problem or an OS problem?

> (3) I want it easy for people to find me (my IP address), so I don't want multiple addresses from the user level. I want one device ID, EID, host address, whatever you want to call it. I want you t…

It is important that people can find you/your device, but I am not convinced they need to find you by historic IP address.

“Pinging” Dino’s computer does not have to happen directly at the network layer to find out that it is alive. To test *a* path to Dino’s computer sure you need the address that that path responds to, but I am not convinced that it is simpler if the address on that network is the same as the address on all of the other networks to which it is attached.

> Yes, I want host multi-homing and mobility. And I want it to work seamlessly.

Yes, I agree but I am not convinced we need to solve this by adding the complexity in L3 and hence through out the whole of the Internet rather than further up the protocol stack.

Stewart

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 2 Dec 2021 14:45:37 +0000

> Yes, I agree but I am not convinced we need to solve this by adding the complexity in L3 and hence through out the whole of the Internet
> rather than further up the protocol stack.

AERO and OMNI do not solve this at L3; they solve it in the adaptation layer (i.e.,
lower down the protocol stack).

Fred

> From: Int-area [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Thursday, December 02, 2021 3:45 AM
> To: Dino Farinacci <[email-masked]>
> Cc: [email-masked]; Dirk Trossen <dirk.trossen=[email-masked]>
> Subject: [EXTERNAL] Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> > (3) I want it easy for people to find me (my IP address), so I don't want multiple addresses from the user level. I want one device ID, EID,
> host address, whatever you want to call it. I want you to "ping <dino's-computer>".
> 
> “Pinging” Dino’s computer does not have to happen directly at the network layer to find out that it is alive. To test *a* path to Dino’s
> computer sure you need the address that that path responds to, but I am not convinced that it is simpler if the address on that network is
> the same as the address on all of the other networks to which it is attached.
> 
> >
> Yes, I agree but I am not convinced we need to solve this by adding the complexity in L3 and hence through out the whole of the Internet
> rather than further up the protocol stack.
> 
> Stewart
> 
> 
> 
> > Speaking as a user,
> > Dino
> >
> >> Many thanks for those participating in the side meeting on Internet addressing during the IETF 112 week. As suggested during the
> meeting, we want to take various points of discussion during the meeting onto the mailing list to continue discussion here on possible ways
> forward.
> >>
> >> Specifically, we wanted to come back on the issue that a larger architectural discussion may be needed, a point that we make towards
> the end of the GA draft (https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/), but which was also core to
> Dirk K’s main point that only such architecture discussion may lead to possibly needed changes to addressing. We will be looking into such
> possibly larger discussion along different possible avenues.
> >>
> >> For our discussion here on the INT area list, we found Dino’s related suggestion particularly useful in that we may need a discussion on
> what we (as users) may want from a network. We feel that our current GA draft may contribute to this question by observing that the many
> extensions to Internet addressing that we have gathered so far may be seen as an expression of a desired feature that those proposing the
> extension may want to see from the network. Hence, in addition to positioning those extensions as identified gaps to Internet addressing,
> we may want to formulate those extensions as desired features towards an extended Internet system, not just addressing; this can be done
> through suitably extending the GA draft with another section.
> >>
> >> Why is this useful? We think that such view provides an observational input into the question that Dino suggests to answer, which in turn
> links to the larger architectural discussion that Dirk K suggests to have. While the overall architectural discussion may (and likely will) touch
> on more than ‘just’ addressing, we as a community may contribute to the discussion by rationalizing the work that has been done in this
> space.
> >>
> >> We would like to solicit thoughts on this proposed way forward as concrete steps for the community here on the list. Also, anybody
> wanting to provide concrete input and contribution to this proposed revision of the draft is more than welcome.
> >>
> >> Best,
> >>
> >> Dirk

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Dec 2021 11:00:36 -0800

> Many thanks for the reply. Let me tie this back to my question regarding the draft: would you think it being a useful exercise to link the extensions described in the GA draft with those desired fe…

Please describe the extension here briefly so people can stay engaged with the discussion. References aren't useful and requires readers to hunt for what you might intend.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Dec 2021 13:04:57 -0800

> It can do this by treating these as independent links with different addresses and bind them in the application or through some OS service.

Its too much complexity for the app. The app is talking to one place and shouldn't know where it is. Hence the network layer should do this.

> Is that a network layer problem or an OS problem?

Yes, its a network layer problem. The OS is just an implmentation of a network stack.

> It is important that people can find you/your device, but I am not convinced they need to find you by historic IP address.

I used this example (at the network layer) due to the audience of the list. What I really want to know is Stewart's crypto wallet address because I want to send you a donation. That is addressing at a specific app level.

> “Pinging” Dino’s computer does not have to happen directly at the network layer to find out that it is alive. To test 

Right but if I want to debug where my crypto transaction is going (I want it to go from my computer to your computer) then I have to go down a level (to the network layer), that is as an engineer (not high-level user) to determine an issue or understand performance.

> *a* path to Dino’s computer sure you need the address that that path responds to, but I am not convinced that it is simpler if the address on that network is the same as the address on all of the other networks to which it is attached.

There is one network. You are one human being with 2 names. I can call you Stewart or Mr Bryant. It doesn't matter you will respond but wouldn't it be better if I called you "my-friend" and packets can go to either Steward or Mr Bryant?

I can tell you could react that this is a stretch, but you get what I'm trying to get across. The physical connection should not matter to the app. And don't forget the physical connection goes up and down, it gets fast and slow, it gets address (i.e. locator) changes. That should be damped out from the app.

> Yes, I agree but I am not convinced we need to solve this by adding the complexity in L3 and hence through out the whole of the Internet rather than further up the protocol stack.

You always have to add something to get something. And what you add can be simple. Just have to make choices very very carefully.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Dec 2021 19:46:04 -0800

> (3) I want it easy for people to find me (my IP address), so I don't want multiple addresses from the user level. I want one device ID, EID, host address, whatever you want to call it. I want you t…
Dino,

I don't want everyone to "ping <tom's-computer>" :-)

Not everyone wants to be easy to find, in fact for privacy it's really
just the opposite. Instead of have one host address, I'd rather have
millions of addresses assigned to my device so that for each
connection I can use different source address and a third party seeing
my packets going to two different destinations couldn't correlate that
they are from the same source and much less that they are from the
same individual. This is fixable with IPv6 with it's immense address
space, but it is going to require breaking the concept that an address
conveys both identity and location of a user.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Dec 2021 19:52:20 -0800

> I don't want everyone to "ping <tom's-computer>" :-)

Then you don't make your EID available. But you can source from it.

> Not everyone wants to be easy to find, in fact for privacy it's really

When I say "everyone" I mean services you want to make available. And you may not want to make them available to the entire world.

> millions of addresses assigned to my device so that for each

You can do that. If the addresses aren't tied to the topology. That is the main point I want to get across.

> connection I can use different source address and a third party seeing

Yes, in the future, we can use random or crypto addresses.

> they are from the same source and much less that they are from the

Right, definitely agree.

Just like you use different credit card numbers for each financial transaction. Just like you use different wallet addresses for each crypto transaction.

> conveys both identity and location of a user.

Agree. But you don't want the app to store the location part. They means if the location is no longer reachable the app has to know that and take action. The app should run business logic and not networking logic.

Dino

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 3 Dec 2021 09:46:39 +0000

Hi Dino,

The extensions are those identified in Section 3 of the gap analysis draft (at https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/). There are 21 extension listed so far (saee Secti9on 4 on Page 21 for an overview). 

Best,

Dirk

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: 02 December 2021 20:01
To: Dirk Trossen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Dec 2021 12:18:48 +0100

- make sure the Internet does no harm.

- use shorter paths and not artificially-long paths like with VPN
   gateways, video session rdv points.  Use more direct communications

- accommodate more bandwidth: 10petabit/s for a link.

- reduce the number of overlays.  Reduce the encapsulations, like IPv6-
   in-IPv4 and others.

- make it easier to avoid address waste.

- promote Internet to space and inter-planetary.

Le 01/12/2021 à 09:52, Dirk Trossen a écrit :
> Dear all,
> 
> Many thanks for those participating in the side meeting on Internet 
> addressing during the IETF 112 week. As suggested during the meeting, we 
> want to take various points of discussion during the meeting onto the 
> mailing list to continue discussion here on possible ways forward.
> 
> Specifically, we wanted to come back on the issue that a larger 
> architectural discussion may be needed, a point that we make towards the 
> end of the GA 
> draft*//*(https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/ 
> <https://datatracker.ietf.org/doc/draft-jia-intarea-internet-addressing-gap-analysis/>), 
> but which was also core to Dirk K’s main point that only such 
> architecture discussion may lead to possibly needed changes to 
> addressing. We will be looking into such possibly larger discussion 
> along different possible avenues.
> 
> For our discussion here on the INT area list, we found Dino’s related 
> suggestion particularly useful in that we may need a discussion on what 
> we (as users) may want from a network. We feel that our current GA draft 
> may contribute to this question by observing that the many extensions to 
> Internet addressing that we have gathered so far may be seen as an 
> expression of a desired feature that those proposing the extension may 
> want to see from the network. Hence, in addition to positioning those 
> extensions as identified gaps to Internet addressing, we may want to 
> formulate those extensions as desired features towards an extended 
> Internet system, not just addressing; this can be done through suitably 
> extending the GA draft with another section.
> 
> Why is this useful? We think that such view provides an observational 
> input into the question that Dino suggests to answer, which in turn 
> links to the larger architectural discussion that Dirk K suggests to 
> have. While the overall architectural discussion may (and likely will) 
> touch on more than ‘just’ addressing, we as a community may contribute 
> to the discussion by rationalizing the work that has been done in this 
> space.
> 
> We would like to solicit thoughts on this proposed way forward as 
> concrete steps for the community here on the list. Also, anybody wanting 
> to provide concrete input and contribution to this proposed revision of 
> the draft is more than welcome.
> 
> Best,
> 
> Dirk
>

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 3 Dec 2021 13:59:50 +0100

Hi Fred,

I see AERO and OMNI as examples of technologies trying to fill a gap (or a few gaps), falling exactly in what has been done in the Gap Analysis draft: surveying technologies that are filling gap in the addressing model.

Ìt would be wonderful if you could formulate the gap(s) that AERO and OMNI fill so that this can be added to the analysis in the GA draft.

What do you think?

Ciao

L.

> On 2 Dec 2021, at 15:45, Templin (US), Fred L <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Dec 2021 08:14:16 -0800

> - promote Internet to space and inter-planetary.

Security/privacy for users is not on your list? IMO that is the #1
priority and the other two in the top three requirements are
ease-of-use and quality of experience (performance, reliability,
availability, etc.).

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Dec 2021 14:21:57 +0100

Thanks for the reply, Tom.

I agree with you in the sense of updating the list, momentarily:

- make Internet to offer security for privacy for users.

- make Internet to be easy to use and offer a very high quality of
   experience in terms of performance, reliability and availability.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 6 Dec 2021 15:47:06 +0100

with respect to the combined 'privacy and security' of Internet, I would
like to point to a problem I see growing recently in the Internet: more
and more I click on URLs that refuse to show me the content.  The
'privacy and security' reasons of these refusals are the following:

In some countries, there is refusal to abide to legislation of other
countries with respect to 'privacy'.  Namely, the site maintainers
disagree with displaying this 'Accept all cookies' proposals to end
users.  If they displayed it I would have happily clicked on it, but
they dont.  They do so (dont force users into selecting to accept
cookies or not), probably, because they want to protect the large
majority of their typical users which might be fed up with this 'Accept
all' button.  That 'accept all cookies' button has its own security
risks, in that its meaning has been faked multiple times.

However, in doing so (refuse to offer option to accept cookies), and by
means of willingness to respect legislation of the country where the
person browsing is situated, they refuse access to that site altogether.

That is access refusal because of Privacy legislation and country
difference.

This is not normal in the Internet I knew before.

In recent months I encountered this situation a few times - I was denied
access to such URLs.  I feel - it is just a feeling - that the number of
such sites might be growing.  If so, this is not good.

The 'privacy and security' should not differentiate between groups of
end users depending on their countries.  Moreover, 'privacy' is that
of an end user versus an Authority (like a gov't), and rarely between
end users themselves. Because consenting adults might expose much of
their privacy, independently of what an intermediary website wants to
allow them to accept or not.  In that sense, a website refusing to abide
the Privacy rulemaking of another country does not really help with many
other well known privacy needs.

Privacy itself might be at loss all while access to information might be
at a loss at a same time.

Alex

Le 06/12/2021 à 14:21, Alexandre Petrescu a écrit :
> - reduce the number of overlays.  Reduce the encapsulations, like 
> IPv6- in-IPv4 and others.
> 
>>> - reduce the number of overlays.  Reduce the encapsulations,
>>> like IPv6- in-IPv4 and others.
>>> 
>>>> Many thanks for those participating in the side meeting on 
>>>> Internet addressing during the IETF 112 week. As suggested 
>>>> during the meeting, we want to take various points of 
>>>> discussion during the meeting onto the mailing list to
>>>> continue discussion here on possible ways forward.
>>>> 
>>>> architectural discussion may be needed, a point that we make
>>>> towards the end of the GA 
>>>>  addressing. We will be looking into such possibly larger 
>>>> discussion along different possible avenues.
>>>> 
>>>> For our discussion here on the INT area list, we found Dino’s 
>>>> related suggestion particularly useful in that we may need a 
>>>> discussion on what we (as users) may want from a network. We 
>>>> feel that our current GA draft may contribute to this question 
>>>> by observing that the many extensions to Internet addressing 
>>>> that we have gathered so far may be seen as an expression of a 
>>>> desired feature that those proposing the extension may want to 
>>>> see from the network. Hence, in addition to positioning those 
>>>> extensions as identified gaps to Internet addressing, we may 
>>>> want to formulate those extensions as desired features towards 
>>>> an extended Internet system, not just addressing; this can be 
>>>> done through suitably extending the GA draft with another 
>>>> section.
>>>> 
>>>> Why is this useful? We think that such view provides an 
>>>> observational input into the question that Dino suggests to 
>>>> answer, which in turn links to the larger architectural 
>>>> discussion that Dirk K suggests to have. While the overall 
>>>> architectural discussion may (and likely will) touch on more 
>>>> than ‘just’ addressing, we as a community may contribute to
>>>> the discussion by rationalizing the work that has been done in 
>>>> this space.
>>>> 
>>>> We would like to solicit thoughts on this proposed way forward 
>>>> as concrete steps for the community here on the list. Also, 
>>>> anybody wanting to provide concrete input and contribution to 
>>>> this proposed revision of the draft is more than welcome.
>>>> 
>>>> Best,
>>>> 
>>>> Dirk
>>>> 
>>>> _______________________________________________ Int-area 
>>>> mailing list [email-masked] 
>>> _______________________________________________ Int-area mailing 
>>> list [email-masked] 
> _______________________________________________ Int-area mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/int-area