On Fri, 22 Jul 2005 15:09:42 +0930
Mark Smith <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Jul 2005 14:20:37 +0930
> Mark Smith <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On Fri, 22 Jul 2005 10:32:48 +0900 (JST)
> > Ryota Hirose <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > >From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
> > > >Date: Thu, 21 Jul 2005 10:19:56 +0200
> > >
<snip>
> > >
> > >
> > > Yes, your idea is a realistic, and also equal to almost current
> > > implementations, I think.
> > >
> > > BTW, suppose following netowrk.
> > >
> > > Internet
> > > |
> > > ROUTER
> > > |
> > > | 100BASE-TX / MTU=1500
> > > |
> > > GbE-SWITCH
> > > | |
> > > | | 1000BASE-T / MTU=9018
> > > | |
> > > HOST1 HOST2
> > >
> > > HOST1, HOST2 and GbE-SWITCH support 1000BASE-T and Jumbo Frames, but
> > > ROUTER has only 100BASE-TX interfaces and doesn't support Jumbo
> > > Frames. In this network, ROUTER will send RA. If the MTU option,
> > > which value is 1500, is included in RA, HOST1 and HOST2 will accept
> > > it, and are disabled Jumbo Frames. So, if we want to use Jumbo
> > > Frambes between HOSTs, (1) HOSTs must neglect MTU option, (2) ROUTER
> > > must send RA without MTU option, (3) or ROUTER must send RA with MTU
> > > option which value is 9018, illegal MTU for ROUTER itself.
> > >
> > > (2) RA without MTU option is always valid. But (1) neglect MTU
> > > option, or (3) MTU option with illegal value for sender itself, are
> > > acceptable?
> > >
> >
> > I'd think not, probably in either (1) or (3), as an interface MTU value
> > implies that the other devices attached to the same segment / link can
> > also receive (and process) the MTU sized frames.
> >
> > To support differing MTU values on a single link/segment, each node
> > would have to somehow keep track of the Maximum Receive Unit value of
> > its link/segment neighbours. PPP supports doing this, and is able to do
> > it because a level of layer 2 parameter negotiation goes on before the
> > link is brought up. It is also simple to do because there is only one
> > neighbour.
> >
> > For this sort of thing to be supported on a multi-access media, such as
> > an ethernet, I'd think some sort of similar, per neighbour, layer 2
> > parameter negotiation of discovery protocol would have to be developed.
> >
>
> Thinking about this a bit more, this could probably be fairly easy to
> achieve by creating a "onlink-MRU" or "interface-MRU" option for ND
> Neighbour Advertisements. There'd need to be some logic in how a sending
> node selects the size of the packets that it sends to a neighbour, based
> on comparing the values of its own local interface MTU, the link's MTU
> as announced in the RA(s) and the target neighbours announced
> onlink-MRU, if it announces one.
>
Looks like this might not be possible, as according to RFC2461,
" variable MTU - Neighbor Discovery allows routers to specify a MTU
for the link, which all nodes then use. All nodes
on a link must use the same MTU (or Maximum
Receive Unit) in order for multicast to work
properly. Otherwise when multicasting a sender,
which can not know which nodes will receive the
packet, could not determine a minimum packet size
all receivers can process."
Certainly understandable, a shame though. I can see more and more SOHO
users buying GigE because it is getting cheap, yet being hobbled to 1.5K
frames because their broadband router doesn't have a GigE interface
supporting jumbo frames. Hopefully SOHO broadband routers start using
GigE jumbo frame capable interfaces, just because they'll be cheap.
Maybe the media default or the RA announced MTU could be used for
multicast traffic, where as a ND discovered best value MRU between
specific neighbours could be used for unicast traffic between them.
<snip>
>
> A ND RA option, indicating the "router-MRU" or "offlink-MTU" value might
> be necessary and useful also.
>
> Necessary if nodes don't issue ND NSes for routers if they have already
> learnt the router's Link layer address via the RA. It may also be useful to
> have an onlink-MRU option as well, to allow for local traffic targetted
> at the router's onlink interface address(es), which may be used for
> administrative access to the router, although probably not necessary for
> the amount of onlink traffic a router receives.
>
> Useful if the router only has one other link, e.g., a link to the
> Internet, and the MTU of that link is smaller than the onlink MTU, a
> good example being a PPPoE 1492 MTU on a ADSL link. The router could
> annouce the other link's MTU as the offlink-MTU (assuming it is smaller than
> the
> LAN interface's MTU), which could avoid a PMTUD cycle for every new
> offlink connection that encounters the smaller 2nd hop MTU.
>
If different MTUs were able to be used for multicast and unicast
traffic, then I think the above could also work out.
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
