On Thu, 14 Sep 2006 10:41:34 -0400
[EMAIL PROTECTED] wrote:

> Hi Mark, the setting of MTU to 1280 will not block larger packets from
> coming in (this will be limited by the physical device capability) but
> will force the packets sent through that IP to be fragmented to a
> maximum of 1280 size packets. The only issue is that we are loosing
> performance by setting it to the lowest value. With setting it to a
> higher MTU we risk that Neighbor Discovery will not work properly with
> devices that support 1280 only. 

Well, in that case, you'd have the problem that my last sentence
avoids ...

"Typically that would be the largest MTU capable of being sent and
received by all devices on the link."

In other words, the smallest Maxiumum Recieve Unit value of the any of
the devices attached to a link/segment constrains all other devices to
being able to send frames no larger than that, despite possible
capabilities otherwise. A good example being an FastEthernet interface
only capable of receiving 1500 byte frames being attached to a GigE
segment with where all the GigE devices (NICs & Switch(es)) being
capable of potentially much larger MTUs. In that case, the "link's
MTU/MRU" is 1500 bytes, no larger.

The only solution at this time to getting your GigE large MTUs back is
to put a router between the FE and GigE devices, which seems to me to
be a bit of a "sledge hammer" approach. Unfortunately at this time, the
sledge hammer is the only tool we've got available. I think it would be
nice if there was some IPv6 mechanism, probably within ND, where
sending hosts could be told "for this neighbour, or for this on-link
prefix, only send frames up to this size". Some of the feasibility of
the per-neighbour MTU was discussed quite a bit on the list a while
back. 

I wonder if the grouping together devices with the same MTU/MRU
capabilities into different on-link prefixes, and then having a
per-prefix MTU would overcome some of the per-neighbour MTU issues
identified at that time.

>It seems to me that one wants to make
> sure that ND is always working properly...
> Do you still maintain your recommendation?
> 
> Thanks,
> Shuki
> 
> -----Original Message-----
> From: Mark Smith
> [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 14, 2006 10:27 AM
> To: sasson, shuki
> Cc: harris, arthur; ting, dennis; viswanadha, kamakshi; [email protected];
> nathanson, daphna
> Subject: Re: MTU on a Link Local Address.
> 
> On Thu, 14 Sep 2006 10:02:02 -0400
> [EMAIL PROTECTED] wrote:
> 
> > Hi all, as we all know Link Local addresses and communicating through
> them are a must in an IPv6 environment. Without it Neighbor Discovery
> will not work and so address resolution.
> > Our system enables one to set an MTU for and IPv6 address. So it is
> very much possible to set the MTU also for the Link Local IPv6 address.
> > The question I have for this forum is what is the MTU value that
> should be set for this Link Local address?
> > 
> > Possibilities:
> > 
> > 1.  1280 --- the reason is that this value would guarantee a
> Neighbor Discovery operation since all devices must support at least
> this MTU.
> > 2.  The MTU of NIC device associated with this Link Local --- All of
> the Neighbor Discovery messages (even the future ones) are guaranteed to
> be less than 1280 so I shouldn't worry about it.
> > 3.  ???
> >
> 
> I'd think it would be the maximum size supported by all devices
> attached to the segment. Remember, link local addressing may not be
> just used for ND, but also any other traffic*, so anything that will
> make the link work most efficiently would be ideal. Typically that
> would be the largest MTU capable of being sent and received by all
> devices on the link. 
> 
> Regards,
> Mark.
> 
> *e.g. telnetting/ftp to a remote router at the other end of a link
> where the router has no other addressing assigned other than LL.
> 
> --------------------------------------------------------------------
> 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
--------------------------------------------------------------------

Reply via email to