Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Friday, February 27, 2015 4:39 PM > To: Templin, Fred L; Ronald Bonica; Carlos Pignataro (cpignata) > Cc: [email protected] > Subject: Re: [Int-area] draft-ietf-intarea-gre-ipv6 > > > > On 2/27/2015 3:50 PM, Templin, Fred L wrote: > ... > > I do not see any "MUST NOTs" in RFC2460, nor any dire consequences for > > allowing a tunnel ingress to fragment atomic fragments. So, if we update > > the final paragraph of Section 5 of RFC2460 we should be good to go. > > On any link that cannot convey a 1280-octet > packet in one piece, link-specific fragmentation and reassembly must > be provided at a layer below IPv6.
Link-specific fragmentation and reassembly of the delivery packet is a pain point that can be alleviated by fragmenting the payload packet. > also: > (Note: unlike > IPv4, fragmentation in IPv6 is performed only by source nodes, not by > routers along a packet's delivery path -- see section 5.) > > So you're talking about updating RFC2460 to allow on-path fragmentation > of source fragments. I disagree with that, for the same reasons it was > omitted from IPv6 in the first place. In this case, the tunnel ingress uses on-path fragmentation of the payload packet instead of link-specific fragmentation of the delivery packet. The tunnel egress is therefore excused from having to reassemble. That is better than link-specific fragmentation and reassembly, and will make for a better IPv6 Internet. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
