Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-01

[Joe Touch <[e-mail]>]

On 12/8/2014 4:11 PM, Ronald Bonica wrote:
> Joe,
> 
> This document UPDATES RFC 2784.  As such, it can be viewed as deltas to RFC 2784.
>
> The introduction to RFC 2784 holds the answer to your question. I include its text below. The final sentence answers your question.

AOK - in that case, this doc ought to be very clear about doing the
same, explicitly.

Which means that any question to this group about how to handle any
given environment is irrelevant. If you're documenting the intersection
of what vendors DO, then that ought not need exploration of hypothetical
and corner cases.

Joe

> 
>                                                                                                  Ron
> 
> Introduction
> 
>    A number of different proposals [RFC1234, RFC1226] currently exist
>    for the encapsulation of one protocol over another protocol. Other
>    types of encapsulations [RFC1241, RFC1479] have been proposed for
>    transporting IP over IP for policy purposes. This memo describes a
>    protocol which is very similar to, but is more general than, the
>    above proposals.  In attempting to be more general, many protocol
>    specific nuances have been ignored. The result is that this proposal
>    may be less suitable for a situation where a specific "X over Y"
>    encapsulation has been described.  It is the attempt of this protocol
>    to provide a simple, general purpose mechanism which reduces the
>    problem of encapsulation from its current O(n^2) size to a more
>    manageable size. This memo purposely does not address the issue of
>    when a packet should be encapsulated.  This memo acknowledges, but
>    does not address problems such as mutual encapsulation [RFC1326].
> 
>    In the most general case, a system has a packet that needs to be
>    encapsulated and delivered to some destination.  We will call this
>    the payload packet.  The payload is first encapsulated in a GRE
>    packet.  The resulting GRE packet can then be encapsulated in some
>    other protocol and then forwarded.  We will call this outer protocol
>    the delivery protocol. The algorithms for processing this packet are
>    discussed later.
> 
>    Finally this specification describes the intersection of GRE
>    currently deployed by multiple vendors.
> 
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Monday, December 08, 2014 6:58 PM
>> To: Ronald Bonica; [e-mail]
>> Subject: Re: [Int-area] Call for adoption of draft-pignataro-intarea-gre-ipv6-
>> 01
>>
>> Hi, Ron,
>>
>> The first - and IMO, only important - question is whether this doc is supposed
>> to document what SHOULD BE or what IS.
>>
>> If you're documenting what IS, there should be no question that any of us
>> need to answer - get a few devices, see what they do and report.
>>
>> If we're talking about that these devices ought to do, we have a lot more
>> work to do, and I don't think it's useful to evaluate any one aspect
>> individually until the doc has been adopted by the WG - which, IMO, ought to
>> include a clear agreement on the scope of the doc.
>>
>> Since we don't have that, I don't agree that wordsmithing is productive yet.
>>
>> So IMO this is something to put a pin in and circle back to once we know the
>> scope of the doc.
>>
>> Joe
>>
>> On 12/8/2014 3:07 PM, Ronald Bonica wrote:
>>> Joe,
>>>
>>> I get your point. How does the following text sound?
>>>
>>> OLD>
>>> Following guidance provided in Section 5 of [RFC2460], GRE ingress nodes
>> SHOULD implement PMTUD, in order to discover and take advantage  of
>> PMTUs greater than the IPv6 required minimum (1280 octets). However, a
>> GRE ingress node MAY simply restrict itself to sending packets no larger than
>> 1280 octets, and omit implementation of PMTUD.
>>> <OLD
>>>
>>> NEW>
>>>
>>> 5. MTU Considerations
>>>
>>> "IPv6 requires that every link in the internet have an MTU of 1280 octets or
>> greater. 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" [RFC 2460].
>>>
>>> IP adjacencies formed by GRE over IPv6 share this requirement. The IP
>> adjacency MUST have an MTU of 1280 octets or greater. This requirement is
>> fulfilled if all permissible routes between the GRE ingress and GRE egress
>> have PMTU greater than or equal to the sum of the following:
>>>
>>> - 1280
>>> - GRE header length
>>> - GRE delivery header length
>>>
>>> It is also satisfied if the following procedure is executed:
>>>
>>> - the GRE ingress encapsulates the payload in a single GRE header and
>>> IPv6 delivery header
>>> - the GRE ingress divides the IPv6 delivery packet into fragments no
>>> larger than 1280 octets
>>> - the GRE egress reassembles the IPv6 delivery packet
>>> - the GRE egress removes the GRE header and IPv6 delivery header <NEW
>>>
>>>                                                                Ron
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Joe Touch [mailto:[e-mail]]
>>>> Sent: Monday, December 08, 2014 10:17 AM
>>>> To: Ronald Bonica; [e-mail]
>>>> Subject: Re: [Int-area] Call for adoption of
>>>> draft-pignataro-intarea-gre-ipv6-
>>>> 01
>>>>
>>>> Hi, Ron (et al.),
>>>>
>>>> The proposed change highlights exactly the problem: only minimal,
>>>> presumably transient versions of IPv6 should be limited to sending
>>>> packets no larger than 1280. I.e., only those versions are supposed
>>>> to omit source fragmentation.
>>>>
>>>> Later in RFC2460 support for 1500-byte fragment reassembly is
>>>> required, so it's not appropriate to quote this section in isolation
>>>> as the sole recommendation for GRE.
>>>>
>>>> Joe
>>>>
>>>> On 12/5/2014 8:38 AM, Ronald Bonica wrote:
>>>>> Joe,
>>>>>
>>>>> Would you agree to the following change?
>>>>>
>>>>> OLD>
>>>>> Following guidance provided in Section 5 of [RFC2460], GRE ingress
>>>>> nodes
>>>> SHOULD implement PMTUD, in order to discover and take advantage of
>>>> PMTUs greater than the IPv6 required minimum (1280 octets).  However,
>>>> a GRE ingress node MAY simply restrict itself to sending  packets no
>>>> larger than
>>>> 1280 octets, and omit implementation of PMTUD.
>>>>> <OLD
>>>>>
>>>>> NEW>
>>>>> In as much as the GRE ingress is an IPv6 node, the following
>>>>> guidance from
>>>> RFC 2460 applies:
>>>>>
>>>>> " It is strongly recommended that IPv6 nodes implement Path MTU
>>>>>    Discovery [RFC-1981], in order to discover and take advantage of path
>>>>>    MTUs greater than 1280 octets.  However, a minimal IPv6
>>>>>    implementation (e.g., in a boot ROM) may simply restrict itself to
>>>>>    sending packets no larger than 1280 octets, and omit implementation
>>>>>    of Path MTU Discovery."
>>>>>
>>>>> <NEW
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Joe Touch [mailto:[e-mail]]
>>>>>> Sent: Thursday, December 04, 2014 1:42 PM
>>>>>> To: Ronald Bonica; [e-mail]
>>>>>> Subject: Re: [Int-area] Call for adoption of
>>>>>> draft-pignataro-intarea-gre-ipv6-
>>>>>> 01
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/4/2014 9:05 AM, Ronald Bonica wrote:
>>>>>> ...
>>>>>>> [RPB]
>>>>>>> The GRE ingress in an IPv6 source. As per RFC 2460, an IPv6 source
>>>>>>> MUST either execute PMTUD procedures or restrict itself to sending
>>>>>>> packets no longer than 1280 octets. How can you argue with that?
>>>>>>
>>>>>> RFC2460 includes sending IPv6 packets up to 1500 bytes that are
>>>>>> reassembled at the destination IP address - in the case of a
>>>>>> tunnel, that's
>>>> the egress.
>>>>>>
>>>>>> Each *fragment* must be no larger than 1280, agreed.
>>>>>>
>>>>>> PMTUD is recommended, not required (it's not a MUST).
>>>>>>
>>>>>> Joe