Re: Protocol and format (Was: New Approach For Discussing IPv10.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think it is worth asking 'what in the world could we do that was meaningfully different'. I did actually come up with an answer.

On Mon, Apr 19, 2021 at 10:25 AM Joseph Touch <touch@xxxxxxxxxxxxxx> wrote:


> On Apr 19, 2021, at 1:50 AM, Stephane Bortzmeyer <bortzmeyer@xxxxxx> wrote:
>
> On Sun, Apr 18, 2021 at 11:42:28PM -0400,
> Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote
> a message of 100 lines which said:
>
>>> You have described the messages only, which alone has never been
>>> enough to define a protocol.
>>
>> Usually that is the case. But IP is a rather peculiar
>> exception. There is lots of stuff above and lots of stuff below and
>> there is the routing layer out to the side. But what is there to the
>> packet layer except the packet format
>
> I agree with you (that IP does not really fit the traditional
> description of a "protocol", for instance it does not have a state
> machine, explicit or implicit) but the same could be said for
> Ethernet, which was a protocol once but now is only a format.

There is a state machine; most of it is degenerate*, but there’s definitely state associated with at least fragmentation reassembly.

*the core state is quite complex in its rules, i.e.,
        net in -> net out includes hop count processing, check for destination accept, ECN marking, DSCP prioritization, and HBH extension processing
        net in -> user out includes ECN relay to transport, E2E extension processing including reassembly
        user in -> net out includes source address determination, DSCP and ECN setting, E2E extension processing including fragmentation

And don’t forget the receipt and generation of ICMPs, RAs, NDs, etc.

Sure, there is some degree of choice at that layer, yet this never seems to be the area people propose to innovate. Its 'lets do a new version of IP so I can have my name on it'.

ICMP, RA, ND etc. are really secondary support, we can change those without changing IPv6, if we change I, we would need to invent a whole new set of support. 


The one approach that is meaningfully different and could work is to dispense with the IPv6 source AND destination addresses and prefix packets with the destination ASN number instead.

So instead of the Internet core routers knowing the IPaddress->ASN tables, they are given the ASN number and an opaque blob.

This approach would require packets to be converted from network format (IPv6) to IPvX format at the network gateway and back again. And of course, packets would have to carry information that allows the IPv6 source/destination to be recovered at the other end. 

That is the road not travelled, or at least not yet. There is only one circumstance where I can see this approach being worthwhile at this point and it is in a mesh network (i.e. mesh in the non Mathematical Mesh sense) that is designed to resist traffic analysis and censorship at a more fundamental level than existing schemes.

And of course, someone will now point out a circumstance where this is already happening because...


 

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux