Re: "RFC 2461bis" issue: MTU handling

[Fred Templin <ftemplin@iprg.nokia.com>]

Thanks Pekka,

However, I believe protocol designers/implementors would appreciate
the flexibility afforded by a new option type.

Fred
ftemplin@iprg.nokia.com

Pekka Savola wrote:

> On Sat, 25 Oct 2003, Bound, Jim wrote:
>  
> > I believe there is another option.  Develop new spec that does number 3
> > below to add to 2461 and leave 2461 alone.  This would be a spec
> > defining a new option for 2461.
> >    
> Or, even define the new interpretation for MTU over NA messages in a 
> separate spec and leave RFC 2461 untouched...?
>
>  
> > > -----Original Message-----
> > > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On 
> > > Behalf Of Fred Templin
> > > Sent: Friday, October 24, 2003 9:06 PM
> > > To: Iljitsch van Beijnum
> > > Cc: ipv6@ietf.org
> > > Subject: Re: "RFC 2461bis" issue: MTU handling
> > >
> > >
> > > I see (at least) three ways for the neighbor-to-neighbor MTU 
> > > negotiation; two were presented in my drafts and the third is 
> > > presented by Iljitsch here. The methods are:
> > >
> > >  1) Change RFC 2461 to allow NA messages to include MTU options:
> > >    Advantages:
> > >      - Unambiguous mechanism for NA's to inform of a 
> > > per-neighbor MTU value
> > >    Disadvantages:
> > >      - Requires modification to RFC 2461
> > >      - May require extra ND messages, since the interpretation of
> > >        MTU options is different for RAs
> > >
> > >  2) No changes to RFC 2461; allow "IPv6-over-foo" documents to
> > >    specify different interpretations of the MTU option in RA's:
> > >    Advantages:
> > >      - No modifications to RFC 2461
> > >    Disadvantages:
> > >      - Ambiguous interpretation of MTU options in RAs, or the
> > >      specified interpretation (MTU for the entire link) is disabled
> > >      - MTU option only available for RAs; not NAs
> > >
> > >  3) Change RFC 2461 to specify a new "NBR_MTU" option  that
> > >    can be sent with either NA's or RAs:
> > >    Advantages:
> > >      -  Unambiguous mechanism to inform of a per-neighbor MTU value
> > >      - Can be used with either NAs or RAs w/o altering the 
> > > interpretation
> > >        of the existing MTU option
> > >      - Maximum efficiency, since it can be used with either 
> > > NAs or RAs
> > >    Disadvantages:
> > >      - Requires modifications to RFC 2461
> > >
> > > So, it should be clear from the above analysis that I support 
> > > Iljitsch's proposal in terms of what should go into RFC 2461. 
> > > It is a sensible approach for a valuable mechanism and I 
> > > think folks should give it the consideration it deserves.
> > >
> > > Fred
> > > ftemplin@iprg.nokia.com
> > >
> > > Iljitsch van Beijnum wrote:
> > >
> > >      
> > > > I'm not sure this should go into a replacement specification for RFC
> > > > 2461, but I'll bring it up anyway:
> > > >
> > > > Currently, routers can advertise an MTU for a link. That's nice. But
> > > > what we really need is a way for hosts to find out the MTU each 
> > > > individual neighbor can handle. 100 Mbps and slower ethernet 
> > > > interfaces can typically handle only the standard 1500 byte 
> > > >        
> > > ethernet 
> > >      
> > > > MTU, while gigabit ethernet interfaces usually support a 
> > > >        
> > > much larger MTU.
> > >      
> > > > However, in most cases hosts with different MTUs are present on the
> > > > same subnet, so simply advertising a larger MTU wouldn't 
> > > >        
> > > solve this. 
> > >      
> > > > (Not that this would work anyway as hosts are instructed to only 
> > > > listen to MTU advertisements where the MTU is between 1280 and 1500 
> > > > (for ethernet).)
> > > >
> > > > But if hosts can tell each other the MTU they support, each 
> > > >        
> > > set of two
> > >      
> > > > hosts is always able to use the largest possible MTU between them. 
> > > > (This would also require a new link MTU option that conveys the 
> > > > maximum MTU the lower layer equipment supports. Switches have their 
> > > > own MTU and even some hubs start doing strange things when a larger 
> > > > than expected MTU is used.)
> > > >
> > > > BTW, some duplication seems to have crept into the document:
> > > >
> > > >   variable MTU   - a link that does not have a 
> > > >        
> > > well-defined MTU (e.g.,
> > >      
> > > >                    IEEE 802.5 token rings).  Many links (e.g.,
> > > >                    Ethernet) have a standard MTU defined 
> > > >        
> > > by the link-
> > >      
> > > >                    layer protocol or by the specific document
> > > >                    describing how to run IP over the link layer.
> > > >
> > > >     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.
> > > >
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > ipv6@ietf.org
> > > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
> > > >        
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> > >      
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> >    
>  


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------