Re: Manual PMTUD [was ...rfc2460bis-08]

[Brian E Carpenter <[e-mail]>]

> I can use
> today SRv6 features in my data centers where I consistently know that all
> interfaces are set for jumbo frames and where hopefully I do not need to
> worry about MTU since hosts have much lower max MTU configured.

Exactly. That's not the Internet. Internet Standards are for the Internet,
hence I believe that the AD's decision is the correct one.

(How would you feel about an extension header that MAY be deleted
by an intermediate node, and MUST be deleted if the next hop's link
MTU is too small? That's the sort of complexity that allowing header
insertion would require in order to be acceptable across the Internet
with broken PMTUD that we have. Also PTB semantics would have to change
from "PMTU is N bytes" to "Packet exceeded link MTU by X bytes", since
the source has no idea how much has been added by intermediate systems.
Or perhaps the intermediate systems would have to send back a new
ICMPv6 message saying "I extended your packet by Y bytes." This is
not straightforward.)

Regards
   Brian


On 18/03/2017 12:11, Robert Raszuk wrote:
> Hello Brian,
> 
> I do suffer from MTU issues over both intranets and Internet the same way
> as you do ... or maybe even more.
> 
> As example there are transit ISPs out there who provide now extra new fancy
> services of DDoS detection except they do not tell that to direct your data
> stream packets to screening devices they encapsulate it in another entire
> IP header to redirect it to this service.
> 
> MPLS encapsulation is also another one. While other then 6PE it happily
> leaves v6 Internet alone there are active proposals in IETF to take it on
> target as well.
> 
> However allowing or not allowing header insertion into IPv6 is IMHO
> orthogonal here. The fact that you forbid it will only result in bigger
> size encapsulation hence lower effective MTU. Services have moved to
> overlay and that requires decoupling them from transport. And in some
> networks service is not just fancy firewall or load balancer ... service is
> basic IPv4 lookup, basic VPN segmentation or tenant micro segmentation. And
> the last one even if it starts on end host it starts not in sourcing VM,
> but in the forwarding host OS kernel's RIB.
> 
> MTU is a valid problem and we should work on it but I don't think it should
> stop IPv6 based services and IPv6 innovation till it is solved. I can use
> today SRv6 features in my data centers where I consistently know that all
> interfaces are set for jumbo frames and where hopefully I do not need to
> worry about MTU since hosts have much lower max MTU configured.
> 
> Kind regards,
> Robert.
> 
> 
> On Fri, Mar 17, 2017 at 11:51 PM, Brian E Carpenter <
> [e-mail]> wrote:
> 
>> Robert,
>>
>> (cc's trimmed)
>>
>> I remember well, back when serial modems were still the norm, sitting
>> in hotel rooms manually cranking back the IPv4 MTU size on my laptop
>> until it was possible to establish TCP connections. Fortunately,
>> somebody had written a piece of freeware that made this possible on
>> Windows 95. I seem to remember having to set the MTU to 256 in Vienna,
>> for example.
>>
>> It is really unthinkable to me to allow header insertion on the Internet
>> until we have a working solution to PMTUD in all circumstances, which we
>> don't, due to operators misconfiguring middleboxes to drop ICMPv6/PTB,
>> and due to RFC4821 being a rarity.
>>
>> When this major operational problem has been solved, it will be time to
>> seriously consider header insertion (including its very non-trivial
>> security implementations).
>>
>> Regards
>>    Brian Carpenter
>>
>>
>>
>> On 18/03/2017 06:06, Robert Raszuk wrote:
>>> All,
>>>
>>> This is very interesting thread indeed.
>>>
>>> I think header insertion at *any* network element be it host, router,
>>> service chain device is highly desired. IPv6 deployments will be much
>> more
>>> successful if we clear any obstacles which otherwise prevent it from
>>> delivering required by customers and operators functionality.
>>>
>>> And I would state that this should be not only limited to one's own IGP
>> or
>>> BGP domain. It should be legal Internet wide.
>>>
>>> Today Internet as a entire system lacks tools to accomplish path
>>> engineering, fast connectivity restoration, p2mp delivery of content etc
>>> ... Some of those are possible with MPLS based tools however as we all
>> know
>>> MPLS has no NNI and does not really work across domains. Here we stand
>> very
>>> close to have a chance to fix it.
>>>
>>> And if one would forbid by spec the header insertion performed by network
>>> elements what's the alternative ... IPv6 in IPv6 encapsulation which may
>>> suffer with even more overhead yet will still require IANA allocation of
>>> SRH type as well as TLV codepoints as effectively encapsulating network
>>> element will be acting as IPv6 sender.
>>>
>>> Concluding I do hope that we can try to collectively make IPv6 protocol
>>> flexible enough to satisfy customer and operator's requirements what in
>>> turn will enrich and speed up IPv6 global adoption.
>>>
>>> Kind regards,
>>> Robert.
>>>
>>>
>>> On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John <[e-mail]>
>> wrote:
>>>
>>>> Thanks Stewart,
>>>>
>>>> This really supports my point and hopefully not the intent or result of
>>>> the discussions here.
>>>>
>>>> We are trying to work through the IETF process to come up with standards
>>>> and solutions that address real operational challenges faced in
>>>> deployments.  For operators, dealing with legacy and migrations are a
>> big
>>>> challenge.
>>>>
>>>> Wishing these issues away and as a result having non-standard
>>>> functionality in “middle boxes” that are ignored in the architecture is
>> not
>>>> productive.  NATs are a way of life, dark space is being deployed by
>> other
>>>> operators, “Cloud”/NFV/ServiceChaining are active areas; tunnels,
>> tunnels
>>>> everywhere - PMTU is always an issue.  “Turtles and Tunnels all the way
>>>> down”.
>>>>
>>>> We are very aggressively migrating to a V6 infrastructure, but there is
>> a
>>>> large amount of old legacy systems/applications/services that need to be
>>>> addressed.  At the same time the allure of “Cloud” attracts systems that
>>>> should never be moved without being re-architected and the
>> virtualization
>>>> environments fully supporting V6 (both Vendors and OpenSource) – but
>> they
>>>> do move and vendors help make that possible.
>>>>
>>>> Hopefully we can keep the discussions going and keep tools available
>> until
>>>> we know we have solutions to deal all the activity happening outside a
>>>> clean end-to-end Architecture,
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> On 3/16/17, 6:44 AM, "Stewart Bryant" <[e-mail]> wrote:
>>>>
>>>>     > In another form, the answer to John is that there are no protocol
>>>> police,
>>>>     > so what consenting adults do inside their own networks simply
>> isn't
>>>> an
>>>>     > issue that an Internet-wide spec can or should address.
>>>>
>>>>     That is not quite true, the inability to gain an IANA allocated
>>>>     codepoint can make long
>>>>     term private deployments very difficult, either for the protocol
>>>>     squatting on a codepoint
>>>>     because they could not get one allocated, or to the deployment of a
>> new
>>>>     protocol
>>>>     legitimately allocated a conflicting codepoint.
>>>>
>>>>     - Stewart
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>
>>
>>
>