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

[Jen Linkova <[e-mail]>]

On Thu, Oct 2, 2014 at 12:35 AM, Joe Touch <[e-mail]> wrote:
> There is no need for multiple documents on this topic. This information
> should be rolled into draft-gont-opsec-ipv6-eh-filtering-02

I agree that those two documents d overlap - especially in the section
of ipv6-ehs-in-real-world  which discusses the security implication of
filtering (I believe it's a very good idea to add either such section
or a reference to this draft to opsec-ipv6-eh-filtering-02). I'm not
so sure if both documents should be merged as one is documenting the
operational experience and the current situation while another one is
providing some recommendations.

>
> 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,
>>



-- 
sincerely yours,
Jen Linkova a.k.a Furry
Network Engineer
Brandschenkestrasse 110, 8002 Zurich, Switzerland
Company Identifikationsnummer: CH-020.4.028.116-1
This email can contain confidential information.If you received this
email by mistake, do not pass it to third parties and delete all
copies and enclosures, and let us know that it has been delivered to
wrong address. Thank you.