As I do not attend meetings, perhaps someone at the meeting could ask the
author these questions:
1)
> 10 - discard the packet and, regardless of whether or not the
> packet's Destination Address was a multicast address, send an ICMP
> Parameter Problem, Code 2, message to the packet's Source Ad
der the API know that)? Is that better or worse
than fragmentation?
I think that FreeBSD has done the reasonable thing. Given that the API
has accepted the packet it is transmitting it using the most recent
information about the path, rather than transmitting it with high
odds of failure.
--
G
On 24/06/2013, at 8:41 AM, Fred Baker (fred) wrote:
>
> I'm in a similar case with respect to protocols above IPv6 (OSPF and NFS/UDP
> come quickly to mind) that depend on fragmentation to deal with the issue. I
> think the Robustness Principle tells us that such applications SHOULD figure
> o
router's configuration?
--
Glen Turner <http://www.gdt.id.au/~gdt/>
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
d specification because all it does is raise ambiguity in the implementer's
mind and send them off to look at other implementations for guidance.
This is much more writing than the issue is worth. My apologies for taking up
your time.
Best wishes, Glen
--
Glen Turner <http://www.gdt.id
The contents of the Line Identification Destination Option are
essentially opaque.
Although this may allow a wide range of router implementations, in
practice it leads to a situation where new implementers must
reverse-engineer the dominant implementation in order to be assured of
compatibility.
