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

On Oct 1, 2014, at 1:33 PM, Warren Kumari <warren@kumari.net> wrote:

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

Might I may a recommendation to also include IPsec wg for some of this discussion and/or mobility
groups.  They are the *only* EH that I know that in the real world might actually be used.  Most
specifically the RH EH Type2 that's used in mobile environments and then the AH/ESP for IPsec.

You may want reach *customers* who are not necessarily 'operators' who are utilizing the EHs.

Just a suggestion :)  The biggest PITA for all vendors are EH….it's my litmus test for all vendors
to see if they REALLY have an IPv6 implementation.  

Caveat - I haven't kept up with this work….will try and read latest draft in next few days

- merike

> 
> 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
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops