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

List:       ipng
Subject:    RE: RFC4821 recommendation (RE: <draft-hinden-6man-rfc1981bis-00.txt>)
From:       "Templin, Fred L" <Fred.L.Templin () boeing ! com>
Date:       2015-11-18 23:05:54
Message-ID: 2134F8430051B64F815C691A62D9831832F5109B () XCH-BLV-504 ! nw ! nos ! boeing ! com
[Download RAW message or body]

Hi Bob,

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Wednesday, November 18, 2015 2:50 PM
> To: Templin, Fred L
> Cc: Bob Hinden; IPv6 List
> Subject: Re: RFC4821 recommendation (RE: <draft-hinden-6man-rfc1981bis-00.txt>)
> 
> Fred,
> 
> > > > 
> > > We have an opportunity to guide the Internet toward eventual healing of
> > > the broken PMTUD wound. We provide gentle guidance by saying only
> > > SHOULD/should, which is a recommendation and not a requirement. It
> > > stands a chance of steering the Internet toward path MTU resilience
> > > instead of brittleness.
> > > 
> > > RFC6434 also has something to say about RFC4821. I believe what I am
> > > suggesting is complimentary to that guidance.
> > 
> > Trying to understand your concern, would the following reword address
> > the issue:
> > 
> > "It is recommended that IPv6 nodes that send packets larger than 1280 bytes
> > to Internet destinations use RFC4821 to overcome silent failures of standard
> > Path MTU discovery. This is especially true for packets larger than 1500 bytes."
> > 
> 
> Yes, something like that.  I will work on some text in the next day or two.

Thanks - I will look forward to reviewing the text.

> Note, I am very open to a new draft that compares the two approaches, says it's \
> important to not drop ICMPv6 Packet Too Big, contrasts the difference between \
> RFC1981 and RFC4821, etc.  To some degree this has been done before, and might be \
> better as a BCP in V6OPS.

I am not sure a comparison draft is needed if guidance like what I 
recommended is folded into RFC1981(bis). In my investigations, I
have come to the conclusion that standard path MTU discovery is
the best solution in environments where it can be relied on, such
as within well-managed administrative domains. That is why I said
that RFC4821 is recommended for *Internet* destinations, since
there is no guarantee that authentic RFC1981-required ICMP PTBs
originating in the Internet will make it back to the original source.

In short, I think 1-2 sentences in RFC1918(bis) will be all that is
necessary if we get it right.

Thanks - Fred
fred.l.templin@boeing.com

> Bob
> 

--------------------------------------------------------------------
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]