Re: [v6ops] IPv6 Extension Headers in the Real World

On Tue, Sep 30, 2014 at 12:50 AM, Fernando Gont <fernando@gont.com.ar> wrote:
> Folks,
>
> Earlier in September we published a revision of our I-D "IPv6 Extension
> Headers in the Real World"
> (<https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world>).
>
> At this point in time, we're interested in knowing whether our I-D is of
> value for the IPv6 ops community, such that we can decide whether to
> continue working/improving it.

Yes please!

Burying our heads in the sand and pretending that they all work fine
in no way helps with V6 deployment.

Having users and operators get burnt because they didn't know about
issues with EH simply leads to people turning off v6 - once bitten,
twice shy...

W

>  Additionally, if there's anything you
> think we've missed in the document, we'd like to hear from you.
>
> Overall, our I-D is meant to provide a reality-check with respect to the
> issues surrounding IPv6 Extension Headers and their use on the public
> Internet. More specifically, its goals are:
>
> 1) Provide data regarding support of IPv6 EHs in the real world.
>
>     This is interesting data to refer people to (e.g., folks
>     developing protocols) regarding the extent to which IPv6 EHs
>     are usable on the public Internet (at least with web, mail, and
>     name servers).
>
>
> 2) Summarize the issues associated with IPv6 EHs (performance, security,
> etc.)
>
>     This is of use for folks concerned with the issues surrounding
>     IPv6 EHs, and covers practical issues.
>
>
> 3) Summarizes the implications of the aforementioned filtering.
>
>     For example, if you're designing a protocol that is meant to
>     work on the public Internet, you may want to provide some fall-back
>     mechanism that does not employ IPv6 EHs.
>
>     Yet another of the implications is the security issue that has
>     been discussed on-list: if e.g. IPv6 fragments are dropped and you
>     can be tricked into generating them, you may be subject to a DoS
>     attack.
>
>
> 4) Flag possible further work
>
>    Here we try to flag areas where the further work may be needed,
>    such as adding fall-back mechanisms to some existing protocols,
>    or avoiding the use of IPv6 EHs where possible.
>
>
> Thanks!
>
> Best regards,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf