[Bp_ipv6] RIPE-554: BCOP Document for IPv6 Equipment Purchase

Izumi Okutani izumi at nic.ad.jp
Thu Nov 10 01:35:57 EST 2016


Thank you Merike - and welcome to the IPv6 BPF ML :)

It would be wonderful if you could add more focus on the state of security feature support in IPv6 by vendors (not limited to devices).
Section 4.2.6. describes the vendor support in our document and this is still very weak in substance.

  4.2.6. Vendors  (text pasted at the end of this email)
  https://docs.google.com/document/d/1RG8PWxOhsxkEJJdwUkUWN0NFg0cnH4i3L7RFMzeYMf8/edit


We'll refer to ripe-554 in here on what should be supported. If you can specify function on what needs more support, that will be very helpful.
We expect the readers to be policy makers and business decision makers so avoiding too much technical details would be good.

Excellent blog about the Estonian case - on how they actually did it and what they observe as a result of the deployment. Thank you for sharing it - we'll reference it in our document.



Izumi


----
4.2.6. Vendors
For ISPs, many routers and access equipment support IPv6. The most recent  mobile devices also mostly support IPv6. All current computer operating systems (OS) support IPv6, therefore, once IPv6 is turned turns by default, users will connect to IPv6 without needing to do any configurations or settings.

However, there are still many consumer devices which do not support IPv6.
There are also several security devices which do not support/sufficient support IPv6, and  need to be addressed for IPv6 adoption:
  - Intrusion detection
  - Firewall
  - VPN gateways:Mixed status of support
  - Monitoring system: You are monitoring two separate devices even though they are the same device and require re-thinking on how to monitor (During the dual stack period)
----

On 2016/11/10 8:50, Merike Kaeo wrote:
> Hello…
>
> Some added notes…
>
>> On Nov 9, 2016, at 6:51 AM, Izumi Okutani <izumi at nic.ad.jp <mailto:izumi at nic.ad.jp>> wrote:
>>
>>> I somehow failed to spot that this documents are not included, specially RIPE-554 might make sense for governments (given that we started it because our government asked us to ;) :) :) )
>>
>> Indeed and would make great addition for our document which cover about state of support by vendors (Section 4.2.6). There is also a part of the document which mentions a request for government to encourage vendor support. If people agree with this, we can also refer to ripe-554 as to what is needed.
>>
>> Any other suggestions on how we refer to ripe-554 in our BPF document is welcome!
>>
>>
>>> As I'm the primary author of both documents and if you want to mention them - I can help with some surrounding text for better understanding what is what.
>>
>> Excellent Jan - thank you very much for volunteering.
>
> I’ll help where RIPE-554 is concerned as well since I am a co-author.  And was very involved in many security related aspects which I do hope get some focus.
>
> Which has me bringing up the point of filtering on extension headers. I apologize in advance for not looking at current version of document as to how this is covered but I am *very* concerned with the operational practice of dropping all IPv6 packets with ANY extension headers.  This means any packets that are fragmented will get dropped.  Which in turn causes issues and potential breakages for some protocols (specifically DNSSEC).  I know Geof Huston has discussed this in some of his talks and certanly there’s references to IETF work and work done by Jen Linkova.  I am hoping there is some language that gives guidance on vendors who should have capability to give granular configuration capability to drop some packets with Extension Headers but have some granularity associated with it.
>
> Also, about 18 or so month ago the largest ISP in Estonia deployed IPv6 and Tarko Tikkan, the main engineer, wrote something up for RIPE NCC Labs:  https://labs.ripe.net/Members/tarko_tikan/ipv6-deployment-in-estonia
>
> If that hasn’t yet been referenced, perhaps useful to do so.
>
> I am currently in Amsterdam and tomorrow speaking at the O’Reilly Security conference but if any more input is needed I’ll be happy to take a look again on Friday or the weekend.
>
> - merike
>
>>
>>
>> Ideally, if there is a comparison of the requirements listed in  ripe-44 and identify areas where there needs to be more equipment support, that would be very nice.
>> Anyone able to help?
>>
>>
>>
>> Izumi
>>
>> On 2016/11/09 22:53, Jan Zorz - Go6 wrote:
>>> On 09/11/2016 13:23, Sumon Ahmed Sabir wrote:
>>>>
>>>> Hi Everyone,
>>>>
>>>> Just to share a good reference for IPv6 Compatibility requirement.
>>>>
>>>> https://www.ripe.net/publications/docs/ripe-554
>>>>
>>>> Can be a good reference for the government policy and also for any
>>>> organization making future purchase decision.
>>>>
>>>> Should come to our document as reference.
>>>>
>>>> Another good one again from RIPE too.
>>>>
>>>> IPv6 trouble shooting for residential ISP:
>>>>
>>>> https://www.ripe.net/publications/docs/ripe-631
>>>
>>> Sumon, thnx!
>>>
>>> I somehow failed to spot that this documents are not included, specially RIPE-554 might make sense for governments (given that we started it because our government asked us to ;) :) :) )
>>>
>>> As I'm the primary author of both documents and if you want to mention them - I can help with some surrounding text for better understanding what is what.
>>>
>>> Cheers from Macedonia, Jan
>>>
>>> _______________________________________________
>>> Bp_ipv6 mailing list
>>> Bp_ipv6 at intgovforum.org <mailto:Bp_ipv6 at intgovforum.org>
>>> http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org
>>
>>
>> _______________________________________________
>> Bp_ipv6 mailing list
>> Bp_ipv6 at intgovforum.org <mailto:Bp_ipv6 at intgovforum.org>
>> http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org
>>
>





More information about the Bp_ipv6 mailing list