Jari Arkko wrote:
Erik Nordmark wrote:
> This still has the operational issue of what happens when > I need extra ports in my office and I get a cheap 4-port hub; neither > the IT department nor my hosts knows that this box is present and it > might not support jumboframes.
I'd favor robustness a lot more than optimization for the highest available MTU size. Whatever we do, lets make sure the protocol can deal with the above case.
> One way to cope with this particular topology, > but no other topologies of varying frame size switches, would be > for the host to exchange a 9k packet with the router before > deciding that it should declare itself 9k capable.
Yes. But somehow I'm worried about this, particularly when the MTU size field in ND is 32 bits. Is there any danger that a false claim of a large MTU size will lead to something bad happening? Or are we relying on the sender's hardware to not accept overly large packets for transmission?
False claims can be mitigated by employing mechanisms to authenticate ND messages, e.g., SEND.
Also, if the IP header is 40 bytes/packet, one exchange of two 9k packets
It is not an exchange of two 9K packets; it is a 9K probe packet followed by a much smaller acknowledgement packet - on the order of the size of a NA message. The MTU/MRU probing is unidirectional.
consumes as much bandwidth as
the overhead from 225 packets -- a 337 K transmission
at 1500 byte MTU. So perhaps you wouldn't like to do this
every time.
I didn't quite catch this - can you re-phrase?
Fred [EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
