Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

This would certainly complicate tracking ingress interface and
applying rules that require ingress interface information to apply
correctly.

Blech.

On 31 October 2017 at 17:30, Ole Troan <otroan@employees.org> wrote:
> Michael,
>
> Without having thought very much about it... I do think requiring a host to accept tunnelled packets to itself by default or not, requires further considerations.
>
> I am aware of no implementation that would support this. I would also be worried about this opening the door for "alternate" paths into the host stack.
> I think you would have to write a draft.
>
> Another aspect of IP in IP is that with the recent troubles we have with doing path MTU discovery and fragmentation at the Internet layer, that might not be the optimal encapsulation for tunnelling anymore.
>
> Best regards,
> Ole
>
>> On 31 Oct 2017, at 02:23, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>
>>
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> I think this is an interesting topic but I'd really rather
>>> seprate it from 6434bis, because we need 6434bis as soon
>>> as reasonably possible, and this will take a while.
>>
>> Well, I tried to raise this while doing 8200, and was told that I should wait
>> until we got to host requirements.
>>
>> I'm inclined to file an errata against 8200 if 6463bis proceeds without
>> dealing with the issue.
>>
>>> We've got ourselves into trouble at least twice with
>>> automatic tunnels. I'm referring to 6to4 (where I share the
>>> blame) and Teredo. They were both IPv6inIPv4 but I think
>>> some of the same risks will arise with IPv6inIPv6. There may
>>> be contexts where automatic decapsulation is safe and makes
>>> sense. There may be others where it generates either operational
>>> black holes or enticing security loopholes.
>>
>>> So I think this needs to be worked as a separate topic, and
>>> I look forward to your draft... :-)
>>
>> I can write a draft.
>> I will write it to update 6463.
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

Attachment: smime.p7s