Protocol 114 was unassigned in RFC 1700 in Oct 1994, which was the last
RFC tabulating protocol assignments. In January 2002, RFCs ceased being
published for protocol number assignments, according to RFC 3232.
Sometime before Feb 1999, protocol 114 was assigned here:
https://web.archive.org/we
> >> Given the number of remaining entries, the task of garbage collection
> seems of little value.
> > Until the day when it seems urgent...
> 109 available out of 256, or 42%.
The catch is that when this breaks, it will break lots of big stuff.
This 1-byte value is shared between IPv4 and IPv6(!
enefiting the vendors indirectly. So the
cost-benefit tradeoff might be more societal (or network-wide) than
individual or corporate. My understanding is that IETF's role is as a
steward of network-wide value, which is why I thought this might
interest IETF.
John Gi
ed on its results in the real world.
Finally, if intarea or IETF knows a way to "make the path to v6 easier",
we welcome such work and recommend approving it. And yet, the community
has looked in vain so far for an IPv6 silver bullet that would obviate
the ongoing demand for IPv4 address
I have general sympathy for things that would improve the ability of end
nodes to send larger packet sizes. As LAN and WAN speeds rise, latency
goes down since each packet takes less time on the medium, but packet
processing overhead goes up, since you must be able to receive 10x as
many existing-
Alexandre Petrescu wrote:
> it might make sense to try to make IPv6 to be quantum resistant.
Relax, have no fear. Both IPv4 and IPv6 are already fully buzzword
compliant. They are climate change compatible, quantum resistant,
neutral to positive in political correctness, forward-looking to 5G,
-user -- a non-starter for mass market
use.
* And with few or no ISPs supporting multicast by default, no end-user
applications that tried to use it ever caught on. So there was
very little demand encouraging other ISPs to enable multicast.
The paper does not seem to address any
Warren Kumari wrote:
> This isn't yet another "let's rewrite part of the header and override
> some bits", nor some new protocol / tunneling thing. It simply notes
> that routers only need to determine the outgoing interface (and
> usually MAC address) for a packet, and so it's perfectly acceptabl
The draft seems entirely too focused on the guts of the per-packet
routing decision. This misses the system-wide implications of the
proposal.
The draft treats IPv4 and IPv6 as symmetric and equal, such that you
could route packets for either or both, over a network that support just
one.
So I s
Matt Mathis wrote:
> - There is not a conformance specification for jumbo, and
> interoperability is not guaranteed
> ...
> - Alarming discovery when PLPMTUD [RFC 4121] was almost done
> - we encountered a device (gbic) that ran error free at 1500B, but
> showed 1% loss at 4kB
If IEEE
nel. Patches needed to do that, if it doesn't already work, would
probably be accepted by the maintainers. Especially if you provided a
patch to the kernel networking test-cases, which demonstrates the failure,
and also demonstrates that your patch elimi
11 matches
Mail list logo
