On 2/26/2015 3:32 PM, Templin, Fred L wrote:
Hi Joe,
-----Original Message-----
From: Joe Touch [mailto:[email protected]]
Sent: Thursday, February 26, 2015 3:11 PM
To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata)
Cc: [email protected]
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
On 2/26/2015 3:00 PM, Templin, Fred L wrote:
Hi Joe,
-----Original Message-----
From: Joe Touch [mailto:[email protected]]
Sent: Thursday, February 26, 2015 2:11 PM
To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata)
Cc: [email protected]
Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6
On 2/25/2015 4:01 PM, Templin, Fred L wrote:
...
I have proposed sending PTB with MTU less than 1280 before as well:
http://www.ietf.org/archive/id/draft-templin-6man-linkadapt-01.txt
The idea is to enlist the original source’s aid in easing the frag/reass
burdens from the tunnel ingress and egress.
IMO, PTB is the wrong message for that.
What we have today is a "Type 0" PTB message.
There are may types for both IPv4 and IPv6.
For IPv4, e.g., PTB is type 3, code 4.
For IPv6, it would be type 2, code 0.
"type 2, code 0" is what I meant when I said "Type 0", yes.
What I proposed was a "Type 1" PTB message.
For IPv6, did you mean type 2, code 1?
Yes; "type 2, code 1" is what I meant when I said "Type 1".
The problem is that legacy receivers will interpret type 2 and ignore
the code.
Yes, but I do not see a problem. If the size reported in the PTB is less than
1280 the source will send subsequent messages as "atomic fragments" per
Section 5 of RFC2460.
Or pick another path. Or break.
That's a code path that isn't commonly exercised.
The tunnel ingress will then know that it is dealing
with a legacy source,
Hosts already generate atomic fragments for other reasons, so that
itself isn't enough to "KNOW" anything.
and will fragment the payload packet using the
fragment header conveniently provided by the source.
That's a violation of on-path fragmentation. RFC2460 gives a very
specific reason for those - focusing on IPv6/IPv4 translation:
...In that case, the IPv6 node
is not required to reduce the size of subsequent packets to less than
1280, but must include a Fragment header in those packets so that the
IPv6-to-IPv4 translating router can obtain a suitable Identification
value to use in resulting IPv4 fragments.
We could argue that this should apply to how fragments tunneled to guide
fragmentation and reassembly in the encapsulating layer (e.g., the
"outer" header), but not to fragment the packet that arrives.
However, all of this is out of scope of the doc we're currently discussing.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
