] What bit is needed ?
]
] Again, this is a layer 2 property. If you want to receive layer 2
] frames with errors in them just get a Layer 2 device and tell it to not
] do the checksum calculation (much like you put an ethernet nic into
] Promiscous mode so it doesn't drop all of the frames not destined for
] it.
a) some apps can deal with lossage, some not. so you want to control
this on a per-packet basis
b) the L2 link in question may not be directly attached to the host
that wants to control this - so you need a bit in the header that
lets the sending host communicate to the link.
]
] As for asking for end-end characterization of this, I think it is
] crazy... The bit can be in your IP header address fields(and on small
] ACK packets, statistically it WILL be there) so the packet wouldn't have
] even made it to your host,
You have to make sure there's adequate protection for the IP header
(and the packet length) even when the payload isn't protected. if the IP
header is corrupted or the packet is a different length than when transmited
on the link, it still has to be dropped.
] it can be in the TCP port fields so it won't
] be received on the correct connection...
I don't think this will ever be used with TCP. This is for apps that don't
want to wait for retransmission of damaged packets, so they probably don't
want to wait for retransmission of lost packets either.
] I would have a hard time taking an IP header bit and making it the "Do
] not drop this packet in the presense of a bit error somewhere in the
] frame from layer 2 - layer 3". Don't think it is a good idea.
I don't know where the bit comes from - there certainly aren't many bits left
in IPv4. It could be a new protocol number, but that's ugly in a different way.
(and dare I say it, it won't work through existing NATs)