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

I'd argue a separate  'problem statement' is a better approach.

--
Tim

> On 1 Oct 2014, at 23:35, Joe Touch <touch@isi.edu> wrote:
> 
> 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,
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops