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

On 10/1/2014 3:44 PM, Tim Chown wrote:
> I'd argue a separate  'problem statement' is a better approach.

If the IETF were developing a new protocol, yes.

But in this case we have operational observations and operational
recommendations. The two are tightly coupled; the latter makes no sense
without the former anyway.

I don't see "here's what I saw" and "here's what to do about it" as
separately useful.

Joe

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