[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01)
From:       Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date:       2016-04-03 20:32:56
Message-ID: 57017DF8.2090601 () gmail ! com
[Download RAW message or body]

On 04/04/2016 03:04, Ronald Bonica wrote:
> Brian,
> 
> Even of somebody saw a Jumbogram at an IXP, it wouldn't be so bad. The IPv6 header \
> would have: 
> - a packet length of 0
> - a next header of HBH
> 
> If the receiving node didn't recognize Jumbograms, wouldn't it discard the packet \
> and send an ICMP Parameter Problem to the source?

Most likely. But my point really was: who cares? Anyone who sends Jumbograms
without knowing that the path supports them will lose anyway.

     Brian
                                                                                      \
Ron
> 
> 
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> > Sent: Friday, March 25, 2016 11:06 PM
> > To: Michael Richardson <mcr+ietf@sandelman.ca>; ipv6 <ipv6@ietf.org>
> > Cc: C. M. Heard <heard@pobox.com>
> > Subject: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-
> > handling-01)
> > 
> > On 26/03/2016 07:35, Michael Richardson wrote:
> > > 
> > > C. M. Heard <heard@pobox.com> wrote:
> > > > Indeed, the question arises whether allowing a router to ignore these
> > > > options beaks them, or not.  Clearly so for Jumbo Payload,
> > 
> > I dispute that, as far as the real world goes. Nobody ever expected the
> > jumbo payload to be used outside a "consenting adults" scenario; the
> > requirement to send back ICMP on discard is really icing on the jumbo cake.
> > As some words in
> > RFC3765 tells you, the path has to be pretty much hand-crafted:
> > 
> > "  On links with configurable MTUs, the MTU must not be configured to a
> > value greater than 65,575 octets if there are nodes attached to that
> > link that do not support the Jumbo Payload option and it can not be
> > guaranteed that the Jumbo Payload option will not be sent to those
> > nodes."
> > 
> > So in practice, it really doesn't matter what the non-supporting router does.
> > Did anybody ever see one of these things at a peering link or an IXP? I very
> > much doubt it.
> > 
> > Brian
> > 
> > 
> > > > but it's
> > > > unclear to me why RPL, MPL, and DFF need to be specified as other
> > than
> > > > ignore if unrecognized.
> > > 
> > > I agree that it's unclear if there is real benefit.
> > > 
> > > --
> > > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software
> > Works
> > > -= IPv6 IoT consulting =-
> > > 
> > > 
> > > 
> > > 
> > > 
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > > 
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> .
> 

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


[prev in list] [next in list] [prev in thread] [next in thread]