RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01

["Templin, Fred L" <[e-mail]>]

Hi Ole,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, February 05, 2016 12:04 AM
> To: Templin, Fred L
> Cc: Fred Baker (fred); Bob Hinden; 6man WG
> Subject: Re: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01
> 
> Fred,
> 
> >
> > I will make one other change recommendation:
> >
> > OLD:
> > It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD)
> > designed for use in environments in which delivery of accurate ICMP messages
> > to a host are not assured.
> >
> > NEW:
> > It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD)
> > designed for use over paths for which delivery of accurate ICMP messages
> > to a host are not assured.
> 
> I would posit that there are no such paths. "accurate" ICMP can never be guaranteed.

Forgetting the word "accurate" for the moment, it is reasonable to
expect that paths that begin and end within the same well-managed
administrative domain can be counted on to deliver the necessary
ICMPs and to not deliver bogus ICMPs. Paths that lead to Internet
destinations on the other hand cannot.

If we do not believe that there are paths for which traditional PMTUD
can still be used safely, then we should be working to deprecate
RFC1981 instead of making it a standard.

Thanks - Fred
[e-mail]

> Best regards,
> Ole
> 
> >> -----Original Message-----
> >> From: ipv6 [mailto:[e-mail]] On Behalf Of Templin, Fred L
> >> Sent: Thursday, February 04, 2016 10:59 AM
> >> To: Fred Baker (fred)
> >> Cc: 6man WG; Bob Hinden
> >> Subject: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01
> >>
> >> Hi Fred,
> >>
> >>> -----Original Message-----
> >>> From: Fred Baker (fred) [mailto:[e-mail]]
> >>> Sent: Thursday, February 04, 2016 10:50 AM
> >>> To: Templin, Fred L
> >>> Cc: Bob Hinden; 6man WG
> >>> Subject: Re: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01
> >>>
> >>>
> >>>> On Feb 4, 2016, at 10:37 AM, Templin, Fred L <[e-mail]> wrote:
> >>>>
> >>>> Your text could be modified by simply adding the word "accurate" as follows:
> >>>>
> >>>> "It defines a method for Packetization Layer Path MTU Discovery (PLPMTUD)
> >>>>   designed for use in environments in which delivery of accurate ICMP messages
> >>>>   to a host are not assured."
> >>>
> >>> So you added the word "accurate". Anything else?
> >>>
> >>> My question would be what makes an ICMP "accurate", and how the host might or might not determine accuracy. As near as I can
> >> tell,
> >>> RFC 1981 says that if a host receives an ICMP Packet Too Big, it should make the packet smaller. If the ICMP has been spoofed,
> >> unless
> >>> the spoofer has done something really egregious, I don't know how the receiving host would know that.
> >>
> >> ICMP spoofing is exactly the point. But, it is not up to the host to determine
> >> whether an ICMP is accurate - it is up to the host to determine whether it is
> >> in an environment in which delivery of accurate ICMP messages is not assured.
> >>
> >>> Given that, I don't think the wording change helps.
> >>
> >> Without "accurate", the text does not address failure mode 2).
> >>
> >> Thanks - Fred
> >> [e-mail]
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------