Re: I-D Action: draft-voyer-6man-extension-header-insertion-07.txt

[Alexandre Petrescu <[e-mail]>]

Le 18/10/2019 à 16:56, Tom Herbert a écrit :
> On Fri, Oct 18, 2019 at 2:23 AM Alexandre Petrescu
> <[e-mail]> wrote:
>>
>>
>>
>> Le 17/10/2019 à 18:19, Tom Herbert a écrit :
>>>
>>>
>>> On Thu, Oct 17, 2019, 6:20 AM Alexandre Petrescu
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>
>>>
>>>      Le 15/10/2019 à 00:12, Fernando Gont a écrit :
>>>       > On 12/10/19 16:57, Brian E Carpenter wrote:
>>>       >> Hi,
>>>       >>
>>>       >> I'd like to comment on this version. It is in fact a complete
>>>       >> rewrite compared to its predecessors and I thank the authors for
>>>       >> that. The tone is now purely technical, and that's a great
>>>       >> improvement.
>>>       >
>>>       > It is somewhat frustrating that the draft still fails to argue why
>>>       > EH insertion instead of encapsulation.
>>>
>>>      As usual, I think one of the reasons is a difficulty in qualifying what
>>>      it means 'encapsulation'.
>>>
>>>      There is IP-in-IP encapsulation.
>>>
>>>      But there is also encapsulation like in transporting, or carrying, by
>>>      means of other intermediary headers, layer2, MPLS, security headers and
>>>      future internet shims and GRE and routing headers.
>>>
>>>      IP-in-IP encapsulation is clearly an alternative to EH insertion.
>>>
>>>      But all the other encapsulations are so messy that one may legitimately
>>>      think that a new EH insert/delete standardized according to good WG
>>>      principles would be proper, universal, and solve all  problems of GRE
>>>      for example.
>>>
>>>
>>> Alex,
>>>
>>> What are the problems of GRE to which you referring?
>>
>> Tom,
>>
>> If I remember correctly, on the negative side, GRE does not work with
>> IPsec security, GRE has no IPv6-GRE-IPv6 deployment, GRE is for
>> limited-domains and does not work across the Internet contrary to VPN.
>>
> Alex,
> 
> I guess maybe you're only considering GRE/Ethernet, but for GRE/IP I
> don't believe any of these negatives are valid. In fact, an IPv6
> packet that contains next header 47, a 4 byte GRE header with first 16
> bits set to zero and Protocol type set to 0x86dd, followed by an IPv6
> packet-- is functionally equivalent to ip6ip6 encapsulation. Also, if
> you want to increase the probability of successful traversal through
> the Internet then GRE/UDP can be used (RFC8086).

One may wonder whether IP/GRE/Ethernet, or GRE/UDP/IP, represents 
encapsulation that avoids the necessity of EH insertion, or does not 
represent such.

>> On the positive side, thanks to its key field, only with GRE it is
>> possible to link together several tunnels such as to increase available
>> bandwidth by aggregating, whereas with IP-in-IP it is not possible.
>>
> Yes an advantage of GRE over just ipip encapsulation is that it's
> extensible, albeit limited in its extensibility which is why we
> developed GUE.

I meant an advantage more issued from implementation, not from 
specification.

The implementation of ip-in-ip tunnelling in linux is with virtual 
interfaces.  These interfaces have only two parameters: local and remote 
address.  The GRE implementation uses a  key behind the scenes, in 
addition to these same two parameters.  That key is what helps a 
bandwidth augmenting implementation to keep up  two tunnels at the same 
time (same 'remote' addresses, but different 'local' addresses), to 
distinguish between them, and to distribute IP packets between the two 
(round-robin is one such fashion).  The ip-in-ip tunnel implementations 
do not allow such distribution, because when you put the same 'remote' 
address on two ip-in-ip interfaces it will use just one such interface.

In such a context, one could imagine using EH insertion with IP-in-IP 
tunnelling: insert a key (in an EH) dynamically, by the endpoints.  This 
could help IP-in-IP classic tunnelling to act like GRE tunnelling, with 
respect to the apps that need to maintain two tunnels at the same time.

Alex

> 
> Tom
> 
>> Alex
>>
>>>
>>> Tom
>>>
>>>
>>>      Alex
>>>
>>>       >
>>>       >
>>>
>>>      --------------------------------------------------------------------
>>>      IETF IPv6 working group mailing list
>>>      [e-mail] <mailto:[e-mail]>
>>>      Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>      --------------------------------------------------------------------
>>>