Top-reply (since there are already a bunch of threaded replies that might benefit from this): Queries are small, and have room in the first packet for EDNS (and often the resulting size will still be < 576). Idea: EDNS "signal" + bits -> tells server the client knows about the new meaning of the 15 bits of QCOUNT, and is sending its client-side version of what those bits are. I.e. the bits are NOT changed from zero in the header in the *query*, only in the *reply* and only if the server understands this EDNS option. IFF a server understands this EDNS parameter, it responds with the corresponding EDNS parameter (possibly without bits, either same EDNS parameter or a sibling parameter), and sets the 15 bits per whatever the rules are. Reason: Putting bits in the header (when mutually understood and agreed upon) ensures they are in the first portion of the response, even if the response gets fragmented. E.g. for entropy, this is an important feature, to protect against things like "fragmentation considered poisonous".
Brian On Wed, Jul 26, 2023 at 4:12 PM George Michaelson <g...@algebras.org> wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over <there>" > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > -G > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
