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

[Joe Touch <[e-mail]>]

There is no need for multiple documents on this topic. This information
should be rolled into draft-gont-opsec-ipv6-eh-filtering-02

Joe

On 9/29/2014 9:50 PM, Fernando Gont 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. 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,
>