Manual PMTUD [was ...rfc2460bis-08]

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 <John_Leddy@comcast.com> 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" <stewart.bryant@gmail.com> 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
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 