Subject: Re: Questions on Configured Tunnel MTU and TOS Byte Settings

From: Roy Brabson <[email-masked]>
Date: Mon, 11 Nov 2002 09:44:27 -0500

Oops - I meant for this to go to NGTRANS and V6OPS.

Roy 

> I've got a few of questions on configured tunnels, as described in 
> draft-ietf-ngtrans-mech-v2-01.txt. 
> 
> - Section 3.2 discusses how to set the tunnel MTU.  It covers the case 
>   where the tunnel MTU size is manually configured, with a default of 
>   1280.  While it discusses capping the tunnel MTU at 4400 when IPv4 
>   path MTU discovery is used, it doesn't discuss a maximum configured
>   value for the tunnel.  Does this mean there is no cap when manually 
>   configuring the tunnel MTU (i.e., the configured tunnel MTU may be as 
>   large as 65515, or even larger if jumbograms are used?)
> 
> - The same section does not discuss what a host should do if it receives 
a 
>   Router Advertisement with an MTU option.  Should the MTU value 
received 
>   be used?  If so, is there a cap associated with this MTU value?  In 
>   other words, if it exceeds 4400 bytes should the value be used?
> 
> - In section 3.5, the TOS byte is defined as being set to 0 unless 
>   otherwise specified.  What exactly does this mean?  That, if RFC 2893 
is 
>   followed the DSCP in the TOS byte may be set to a non-zero value?  Or 
>   that RFC 2893 and RFC 3168 should explicitly NOT be implemented for 
>   configured tunnels?  If the latter, I think some discussion on exactly
>   WHY these two RFCs are not to be implemented would be helpful.
> 
> - In section 3.6, the TOS byte of the inner packet is left unmodified at 

>   the tunnel egress.  This seems to contradict some of the referenced. 
>   For instance, RFC 3168 defines both limited-functionality and 
>   full-functionality support for ECN support over tunnels.  For 
>   limited-functionality, which seems to most closely match what is 
>   described in this draft, it discusses what to do at the tunnel egress 
if 
>   the CE option is set in the outer packet header but not the inner 
packet 
>   header.  This processing does not seem to match what is described in 
>   this draft.  Is this intentional?
> 
> Roy
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------