I seem to have gotten my wires crossed and thought the I-D cutoff date was October 31st. No big deal; here are a couple of draft updates relating to this subject thread that I will be submitting when the I-D Registrar re-opens for business:
http://www.geocities.com/osprey67/ndiscmtu-01.txt http://www.geocities.com/osprey67/tunnelmtu-02.txt
Comments welcome,
Fred Templin [EMAIL PROTECTED]
Fred Templin wrote:
Jari Arkko wrote:
Fred Templin wrote:
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.
SEND can assure that RAs come from an authorized router, and that NAs come from the owner of an address. SEND may not be able to assure that the sender of an NA is trusted. That is, we know it comes from the node in question, but we may not be able to trust all the parameters it sends. In conclusion if the MTU info comes from a router, SEND is sufficient, but if its host to host, SEND may not be sufficient.
Well, maybe we should only accept MTU negotiations from routers then; at least that's better than nothing at all.
Anyway, I still think this danger is _mostly_ a non-issue -- your regular 10 Mbit/s ethernet hardware would hopefully decline to send a 2^32 byte probe packet and spend 3400 seconds sending it. However, there might be some special network technology where this might be an issue. Anyway, anything beyond 2^16 would require a jumbogram.
Agree in terms of the danger being _mostly_ a non-issue. We can use SEND to ensure that RAs indeed come from an authorized router (thanks for clarifying this) so we don't run the danger of sending too-large or too-small packets to final destinations for which the authorized router serves as next-hop.
In the case of host-to-host, the worst that can happen when SEND is used is that the receiving host could misinform the sender of the MTU size. Whether the bad size is too small or too large, in the long run it is only the receiver itself (i.e., the sender of the bad MTU information) that will suffer.
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?
I'm assuming the reason for choosing a larger MTU is to save in header overhead and processing time. But the savings in header overhead must be balanced against the cost of negotiating a larger MTU, particularly if that negotiation involves sending large probe packets.
So, one 9K probe is about the same size as the overhead from extra 225 IPv6 headers. Using the standard 1500 byte MTU you get to send about 337 K before spending this much in overhead. That is, a 9K probe packet does not make sense bandwidth-wise if you are communicating less than 337 K with your peer.
Sure; and it only gets worse for links with larger MTUs to probe.
Well, that about wraps it for me - I guess we'll just go ahead and use the data packets themselves as probes then.
Fred [EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
