Re: [v6ops] proposed TCP MSS text for rfc6204bis

Why would Ethernet header size be subtracted in that equation, since RFC894 (in 1984) had already specified 1500B size IP packet over ethernet? I am puzzled.

http://tools.ietf.org/html/rfc894
..
   The minimum length of the data field of a packet sent over an
   Ethernet is 1500 octets, thus the maximum length of an IP datagram
   sent over an Ethernet is 1500 octets.  Implementations are encouraged
..

Cheers,
Rajiv

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Warren Kumari
> Sent: Tuesday, May 22, 2012 1:16 PM
> To: Rémi Després
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] proposed TCP MSS text for rfc6204bis
> 
> 
> On May 22, 2012, at 11:42 AM, Rémi Després wrote:
> 
> > Hi Warren,
> >
> > Le 2012-05-21 à 16:49, Warren Kumari a écrit :
> >
> >> [ Top posting / meta questions ]
> >>
> >> So, both my memory and my google-foo are failing me...
> >>
> >> Can anyone remember *why* the v6 in MTU is 1280 (and please don't say
> >> "Because the RFC says so!"...)
> >
> > In the excellent French book in which I learned IPv6 in 2003
> (livre.g6.asso.fr/index.php/Format_du_paquet_IPv6), here is what I
> learned:
> > "Choice of 1280 as minimum MTU is to permit IPv6 tunneling. 1500 octets is
> the generally admitted link MTU, that imposed by Ethernet."
> >
> > As this permits multiple tunneling layers without fragmentation on the
> most typical links, and limits to a moderate ratio waste of bandwidth on
> 1500-octet remote links, this is IMHO a valuable choice.
> 
> Yes,  I get that it is to accommodate tunnel overhead (and still fit in an
> Ethernet frame),  I was more wondering why the overhead was chosen as
> 220 bytes and not 216 or 247 or 196.324.
> 
> I received this off-list (including with permissions):
> 
> "Hi Warren,
>     Off-list since I cannot find a definitive reference at this point.  The 1280
> number was codified in RFC 2460 based on a back of the envelope
> calculation by Steve Deering either before or during the Fall 1997 IETF
> meeting.  Starting with the Ethernet MTU of 1500, he subtracted the size of :
> ethernet header, IPv6 header, IPv4 header (tunneling), and several possible
> extension headers.  That put the number at 1280 (with some rounding to a
> 64-bit boundary)."
> 
> 
> W
> 
> 
> >
> > RD
> >
> >
> >
> >> I have some niggling voice in the back of my head making 3GPP noises,
> >> but...
> >>
> >> W
> >>
> >> On May 20, 2012, at 10:04 AM, Mark Andrews wrote:
> >>
> >>>
> >>> In message <4FB89733.2080106@gmail.com>, Brian E Carpenter writes:
> >>>> On 2012-05-19 22:26, Randy Bush wrote:
> >>>>>> If you want to send packets of arbitrary size, in any environment
> >>>>>> where PMTUD is impossible or fails, won't you need to always
> >>>>>> include a fragmentation header in every packet greater than 1280?
> >>>>>
> >>>>> see discussion of jumbo frames, commonly 4k or 9k, between
> >>>>> consenting adults on known links
> >>>>
> >>>> Yes indeed, but that isn't the general case. Across the open
> >>>> Internet, I think we have the situation I described.
> >>>>
> >>>> On 2012-05-19 21:16, Gert Doering wrote:
> >>>>
> >>>>>>> UDP packets larger than 1280 bytes Don't do that!
> >>>>>
> >>>>> Tell that to the DNS people.  They seem to really like not-using-TCP.
> >>>>
> >>>> Yes, but I understand that DNSSEC more or less dooms that plan
> anyway.
> >>>>
> >>>> However, I thinks it's true that the only fail-safe solution is to
> >>>> include a frag header if you need to send UDP >1280.
> >>>>
> >>>> Brian
> >>>
> >>> For DNS we just fragment at 1280 using IPV6_USE_MIN_MTU.   We were
> >>> thinking about this back in 1998 (draft-ietf-ipngwg-bsd-frag-00.txt)
> >>> which was rolled into the advanced socket api.  It took a few more
> >>> years than I would have liked to become RFC and for implementations
> >>> to be available.  EDNS was already being developed back then and it
> >>> was obvious that PMTUD wouldn't work for large nameservers even if
> >>> they got the ICMPv6 PTBs.
> >>>
> >>> For DNS there is little to be gained by trying to send any bigger
> >>> packets.
> >>>
> >>> YMMV for other UDP based protocols.
> >>>
> >>> Mark
> >>>
> >>>>  Brian
> >>>> _______________________________________________
> >>>> v6ops mailing list
> >>>> v6ops@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/v6ops
> >>> --
> >>> Mark Andrews, ISC
> >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> v6ops@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>>
> >>
> >> --
> >> With Feudalism, it's your Count that votes.
> >>
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> 
> --
> With Feudalism, it's your Count that votes.
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops