Fred,
Regarding you first comment, the approach taken by RFC 2473 is similar, but not
identical to the approach taken by draft-ietf-intarea-gre-ipv6. Please compare
the text in RFC 2473, Section 7.1.b to the corresponding text in Section 3.1 of
draft-ietf-intarea-gre-ipv6.
Even though the approaches diverge slightly, draft-ietf-intarea-gre-ipv6 should
not UPDATE RFC 2473. draft-ietf-intarea-gre-ipv6 UPDATES GRE encapsulation
procedures, that are defined in RFC 2784. . Therefore,
draft-ietf-intarea-gre-ipv6 UPDATES RFC 2784. It does not UPDATE IP-in-IP
encapsulation procedures, that are defined in RFC 2473. Therefore, it shouldn't
UPDATE RFC 2473.
Regarding your second comment, I think that we can safely ignore the issue of
loss or forgery of ICMP PTB. That problem is inherent to IPv6 fragmentation,
and is not specific to tunnels.
However, we must address the problem that occurs when the tunnel ingress
receives an ICMP PTB with an MTU < X. First, the tunnel ingress must decide
whether to update its estimate of the PMTU. This decision is beyond the scope
of this document, as it is not unique to encapsulation. Every IPv6 node has to
make this decision, regardless of whether it is a tunnel endpoint.
Assuming that the tunnel endpoint updates its estimate of the PMTU, and the
resulting GMTU is lower than 1280, the tunnel endpoint has another decision to
make. When it receives a packet with size > GMTU, it can either:
- discard the packet and send an ICMP PTB, or
- Fragment the delivery header
The current draft specifies a configuration option that governs this decision.
Ron
> -----Original Message-----
> From: Templin, Fred L [mailto:[email protected]]
> Sent: Tuesday, February 24, 2015 10:49 AM
> To: Ronald Bonica; [email protected]
> Subject: RE: draft-ietf-intarea-gre-ipv6
>
> Hi Ron,
>
> > -----Original Message-----
> > From: Int-area [mailto:[email protected]] On Behalf Of Ronald
> > Bonica
> > Sent: Tuesday, February 24, 2015 6:22 AM
> > To: [email protected]
> > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> >
> > Hi Fred,
> >
> > Inline.......
> >
> > >
> > > Message: 1
> > > Date: Mon, 23 Feb 2015 16:50:27 +0000
> > > From: "Templin, Fred L" <[email protected]>
> > > To: "[email protected]" <[email protected]>
> > > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
> > > Message-ID:
> > > <2134F8430051B64F815C691A62D9831832DFB25B@XCH-BLV-
> > > 504.nw.nos.boeing.com>
> > >
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > > Hi, I have a comment on this document. 'draft-ietf-intarea-gre-ipv6'
> > > is very much in the same boat as RFC2473 in terms of MTU and
> > > Fragmentation considerations. So, why not just cite Sections 6.7 and
> > > 7 of RFC2473 instead of inventing new text here since the considerations
> are exactly the same?
> > >
> > [RPB]
> >
> > RFC 2473 addresses the same problem for IP-in-IP encapsulation. It stands
> to reason that the two approaches would be similar.
>
> Not similar - identical.
>
> > However, the text in RFC 2473 is a proper subset of the text in
> > Section 3.1 of draft-ietf-intarea-gre-ipv6. Since much of the text in
> > draft-ietf-intarea-gre-ipv6 is new, for the sake of readability, it makes
> sense to restate the part that is also presented in RFC 2473.
>
> I disagree. RFC2473 is an already-published standard that specifies MTU and
> fragmentation considerations that apply also to this document. This
> document should therefore cite the RFC2473 text normatively.
>
> If you think there is something new to be said in this document, then that
> should also update RFC2473. But, I don't see where this document is saying
> anything new.
>
> > > But then, there would still be three problems inherent in both
> documents:
> > >
> > > 1) There may be no way for the tunnel ingress to determine the MTU on
> > > the path to the egress, e.g., if ICMP PTB messages are lost or
> > > somehow
> > > forged by an attacker
> > >
> > [RPB]
> > Isn't loss or forgery of PTB messages a well-known issue for IPv6,
> regardless of whether any tunnels are involved?
>
> Tunnels can address these issues by ignoring ICMP PTB messages that report
> a size smaller than 1500 bytes.
>
> > > 2) ICMP PTB messages may be lost on the return path from the tunnel
> > > ingress to the original source
> > [RPB]
> > Same comment as above
>
> What is missing is a recommendation for original sources to use RFC4821.
>
> > > 3) Even in environments where 1) and 2) are not a matter of concern, the
> > > original source could see an MTU smaller than 1500.
> > [RPB]
> > This is addressed in Sections 4.1 of draft-ietf-intarea-gre-ipv6.
>
> What I mean is, if the tunnel does not support a guaranteed minimum MTU
> of 1500 bytes then a PTB message reporting a size less than 1500 bytes would
> need to be returned to the sender. If that PTB message is lost, the result is
> a
> black hole.
>
> So, what I am saying is that tunnels should support a guaranteed minimum
> MTU of 1500 bytes as in 'draft-templin-aerolink'. This is not addressed in
> your
> document.
>
> Thanks - Fred
> [email protected]
>
> > Ron
> >
> > >
> > > These issues are addressed by Section 3.13 of
> > > 'draft-templin-aerolink', which is applicable for all tunneling
> > > environments. What is in RFC2473 right now (and what
> > > 'draft-ietf-intarea-gre-ipv6' should be citing) is only applicable for
> controlled environments.
> > >
> > > Thanks - Fred
> > > [email protected]
> > >
> >
> > _______________________________________________
> > Int-area mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
