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. 

Can you be more specific as to where?

This abstract doesn't clearly explain whether it's documenting current
protocols - with all their associated flaws - or proposing a new
variant, some aspects of which differ from what was available when the
doc was first developed.

I need to know whether we're reporters or dancers (on the head of a pin).

Joe

> I include its text below. The final sentence answers your question.
> 
>                                                                                                  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