Re: Limited Domains:

[Toerless Eckert <[e-mail]>]

On Thu, Apr 29, 2021 at 07:04:29AM -0700, Tom Herbert wrote:
> Yes, to the extent that LDs are not used as a rationale to create regional
> dialects of standard protocols that are non-conforming or not interoperable
> with nodes outside the domain.

I guess we would have to write down exactly what we mean with "conformance"
or "interoperability" to be sure we talk about the same thing, but 
i would say that "interoperability" is IMHO the most core
requirement.

E.g.: If i come up with a better header than the IPv6 header, for
example lets say simply allowing variable long addresses (and keep
everything else the same, just for the sake of the example), then that
to me would be a valid option. But how would we call it...
"backward compatible, conforming, interoperable" ?

Technically it could support 1:1 transformation between proper IPv6
packets and the subset of that new header packets that represent iPv6 packets
(lets say also for the sake of simplicity all 128 bit address packets).
Aka: This would not be different to some pre-existing header transformations
such as header compression (although this wouldn't be compression for the
128 bit addresses).

While there are other goals of interest, this is the discussion about
whether we could have new better headers that functionally are a superset
of what IPv6 does plsu stuff that the header does and that goes beond
IPv6 (RFC8200) would have to stay in the limited domain.

Which i think would be very easy to show because once such a packet hits a router
that on the outgoing interface only has an IPv6 neighbor, it would need
to translate the packet to IPv6, and it wouldn't translate, so drop/icmp.

This just gives us a lot more freeedom to build better packet encoding
than if we'd be constrained to just rfc8200. As i gave the example
in before: We could fit IP Multicast into IPv4/IPv6 because it could
fit the available addressing. We couldn't do the same for BIER. So
instead of repeating the one-off new headers (like we had to do for
BIER), lets try to figure out what more flexible header would suffice
to add new semantics.

> > If so, however, couldn't a more flexible addressing be one of those ways,
> > among others?
> 
> Sure, as long as conformance with RFC8200 and other standards is
> maintained. For instance, I'd like to see every flow get assigned it's own
> unique source address to prevent correlations being made by third parties
> on the Internet that different flows are sourced from the same user (CGNAT
> already does this somewhat).

What the most simple explained example fot this ? I am asking,
because i think you can not well technically defend against your
access service provider doing this correlation (at least down to
subscriber level), so to protect against a snooping access provider,
legal rquirements seem to be more appropriate. And the cloud services
themelves would perpass all data they want from higher layers
due to the wonderful world of browsers and untrustworthy apps. So,
who else along the path poses the biggest risk ? Specifically because
different attackers have totally different amount of money for the
attack and distribute it differently. Some naughty security agency
could easily redirect resources to individual target as opposed
to those attackers more interested in full spectrum marketing analysis.

Cheers
    Toerless

> Tom
> 
> 
> > Best,
> >
> > Dirk
> >
> > -----Original Message-----
> > From: ipv6 [mailto:[e-mail]] On Behalf Of Tom Herbert
> > Sent: 29 April 2021 02:42
> > To: Toerless Eckert <[e-mail]>
> > Cc: 6man WG <[e-mail]>
> > Subject: Re: Limited Domains:
> >
> > On Wed, Apr 28, 2021 at 4:59 PM Toerless Eckert <[e-mail]> wrote:
> > >
> > > On Wed, Apr 28, 2021 at 10:51:03PM +0200, Tony Przygienda wrote:
> > > > yepp, researchers are having fun unencumbered largely by harsh
> > > > realities
> > >
> > > Well, the better researcher attempt to get more of an understanding of
> > > the harsh realities by working with whats available to them, which is
> > > quite limited - a few P4 platforms. This lack of openness to
> > > multi-party innovation is what causes high-speed router platforms to
> > > become less and less relevant and devolve into commodities, at least
> > > at the level where folks in IETF are interested in them. Obviously the
> > > spped&feed hardware level will stay an ongoing motor of innovation and
> > > maybe even sales margin, but for the packet layer forwarding, we can
> > > close shop if we do not have a strategy to allow new markets/innovation
> > to be brought in.
> > >
> > > Heck, take a look at the challengers in 5G/6G. They are already moving
> > > purely into general purpose CPU because those challengers have no way
> > > to put innovation into accelerated forwarding hardware due to lack of
> > > access, complexity and also being stuck in a world of standards such
> > > as GTP that make innovation difficult.
> > >
> > Toerless,
> >
> > While I agree with your sentiment, this is really a lament about a segment
> > of the market not about anything IETF has done. For instance, no IETF
> > standard  requires high performance routers to be implemented in fixed
> > ASIC, in fact I believe the technology has evolved to the extent the
> > datapath could go through the CPU simultaneously achieving both performance
> > and flexibility (my company is working precisely on that).
> >
> > The hard problem is legacy and the Least Common Denominator effect. On the
> > Internet we are bound by the least common denominator of protocols which is
> > plain TCP/IPv4 and TCP/IPv6 that generally make it through the Internet.
> > UDP is looking a little better, at least because of QUIC which took a
> > behemoth to force support. The end result of all this is the ossification
> > of the Internet which as you point out stifles innovation and creation of
> > new markets. This is actually the appeal of limited domains, it creates
> > walled gardens where in which the least common denominator can be raised
> > and we can innovate in that sand box, however limited domains don't address
> > the underlying issue unless their scope continually expands to cover more
> > and more of the Internet.
> >
> > Tom
> >
> > > Its totally incomprehensible to me, why engineers who paycheck
> > > ultimately depends on hardware that already is way more flexible than
> > > what our current protocols use do not try harder to think about better
> > > models for third parties to get more value from this hardware. More
> > > flexible, programmable packet forwarding options are one core option
> > > here. And obviously no sane customer wants something thats not
> > > multi-vendor in this space which is where IETF could come in. And no
> > sane network operator wants another protocol silo.
> > > Which is where IPv4/IPv6 compatibility comes in as a base level
> > expectation.
> > >
> > > > while meanwhile large scale IP forwarding is still governed by the
> > > > microcents/bit payload that customers can run their business
> > > > profitably at and this is governed in turn by the merciless trifecta
> > > > of physical laws of power/cooling/space that did not only not change
> > > > in the last 50 years but last 500 and probably much longer even
> > > > before Newton laid his cranium under the said apple tree ...
> > >
> > > When single-family home systems are built from 19" CPU server racks
> > > providing compute across FTTH and powered by solar electricity, i
> > > think we are also starting to see big shifts in the economics of those
> > > core factors. But thats digression.
> > >
> > > I think we agree that from the protocols we remember, IP/IPv6 has done
> > > a pretty good job providing value out of the hardware deployed. But we
> > > also know that other protocols like Ethernet and MPLS have shown other
> > > sectors where they are doing better. So it seem to me obvious that as
> > > developers we should look ahead and see what it is we can best do to
> > > crearte more value. And certainly we know our hardware can already do
> > > more than what is utilized by the protocols.
> > >
> > > Cheers
> > >     Toerless
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >

-- 
---
[e-mail]