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

>  I'm an operator, and I don't want it.

If you don't want it - do not use it.

> and NAT is bad enough.

While I am not a NAT supporter imagine you are running an enterprise with
15,000 CEs each connected to customers with different (and often
overlapping) IPv4 networks. You have a choice to do local proxy at all
customer sites for all types of services you offer or do NAT and get
customer's queries to your POPs. Just think what makes sense and what not
in such scenario.

Best,
R.

On Thu, Nov 30, 2017 at 10:27 PM, Mark Smith <markzzzsmith@gmail.com> wrote:

>
>
> On 1 Dec. 2017 6:35 am, "Robert Raszuk" <robert@raszuk.net> wrote:
>
> Hi Fernando,
>
> So in the case of encapsulation you normally put the node performing the
> encap as source address. That may impact how you handle this packet via
> number of services or even by src-dst routing correct ?
>
> So while perhaps some may consider it "cleaner" I think both variants have
> their own use cases and should be supported.
>
>
>
> The trouble is they're not explained at all.
>
> All there is is an assertion that "operators want this", which is the
> logical fallacy of an appeal to authority.
>
>  I'm an operator, and I don't want it. I think it'll be harder to
> troubleshoot than NAT over the Internet and NAT is bad enough.
>
>
> Thx,
> R.
>
> On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont <fgont@si6networks.com>
> wrote:
>
>> On 11/30/2017 08:45 PM, Ole Troan wrote:
>> >>
>> >> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
>> >> -- this is the standard, straightforward and most clean approach.
>> >
>> > The best example I've heard is when you don't have a natural tunnel
>> endpoint to encapsulate to.
>>
>> What's a natural tunnel-endpoint here? Aren't you expecting such
>> endpoint to exist, to remove the inserted EH, after all? (and listing it
>> in the RH)
>>
>> I seem to remember some folks arguing that the rationale for EH
>> insertion is that performance go to hell if they do proper
>> encapsulation...
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>