Le 20/12/2021 à 10:44, Jiayihao a écrit :
Sourceless Network Architecture or proposals that related are quite
an vivid example of innovation expected to be happened.
Challenges are how/where the proposals at such architectural level
could happen at current Internet? (which is expected to be pervasive
IPv6 but still dominated by IPv4)
I deployed one or two boxes that sent wireless advertisements to
vehicles around it. These advertisements were on IPv6 but needed no
reply. The source addresses were useless for anybody.
These wireless advertisements are 'PoI': points of interest. They tell
that in that area there is a certain interest, such as the fact that
_there_ are sandwiches available, or electric charging spots for
vehicles. The 'there' is an inherent characteristic of the link where
these advertisements were sent. It is a WiFi-like link, with regulated
power levels (e.g. 33 dBm). That power level gives a radius of
approximately a few hundred meters.
A car receiving such a PoI on IPv6 does not need to reply back. Its
driver only needs to learn that in that area there is a certain
interest. It is one-way communication.
This kind of out-of-band communication is a strike-through the layers in
the stack: the valid information generated by the app layer directly
uses capabilities of the PHY layer.
This kind of 'strike-trough' the layers is also necessary when using
GNSS localisation: the validity of the localisation information (e.g.
lat. long. numbers) depends extensively on a 'quality' factor out of the
PHY layer. If the PHY layer data is better sensed and better
calculated, then the APP layer data is more precise.
Sending an NMEA statement over IPv6 would certainly not need source
addresses in IPv6 headers, because no GNSS receiver ever replies NMEA to
a satellite. There might be some uplink data in Galileo or GPS, but
that does not concern localisation: the satellites dont localise
themselves using data from ground. It is a undirectional communication.
Alex
Geoff’s view that host and replicated contents are in a same limited
domain is feasible, but still need to answer that how to make
innovations (or even a private protocol/architecture if needed, like
SNA) happened from a network perspective?
Thanks,
Yihao Jia
--------------
That’s different Brian. That is a packet header without a source
address. Which “could” change the format (or if one decides at the
same time to have the destination address 256 bits long).
I was roughly suggesting using the IPv6 header, as is, and just
scramble the source address bits.
Dino
On Dec 18, 2021, at 6:05 PM, Hesham ElBakoury
<helbako...@gmail.com>
wrote:
There is also this thesis: A better Internet without IP addresses
https://web.cs.wpi.edu/~cshue/research/dissertation_web.pdf
Hesham
On Sat, Dec 18, 2021, 2:47 PM Brian E Carpenter
<brian.e.carpen...@gmail.com> wrote:
On 19-Dec-21 11:34, Dino Farinacci wrote:
From a user perspective, the choice is clear: privacy and
security are
top requirements. We know that payload encryption goes a long
way, and
hopefully encryption of the transport layer headers will
become
dominant so that intermediate nodes will stop meddling and
ossifying
the transport layer. But not everything can be encrypted, the
IP
addresses for instance, so providing real security and
privacy at the
plaintext network layer should be on the list of features to
support
user requirements.
Definitely agree Tom.
But what if we sent a packet where the source address was
encrypted? Then you could have global unique addresses (if you wanted
them). Of course key exchange and rekeying parameters would have to
be setup prior to sending a single packet.
It's called SNA (Sourceless Network Architecture):
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf
Brian
Maybe its just simpler to randomize addresses.
Dino
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing
list Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
