Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment"
Dear colleagues, Following up on feedback received from the community during and after the publication of the ripe-501. The authors have worked on a replacement document, incorporating suggestions made by the community and clarifying some of the requirements. Prior draft versions of this document have been posted to this mailing list in the past months. The resulting final draft document is now published on the website and reachable via https://www.ripe.net/ripe/docs/other-documents/requirements-for-ipv6-in-ict-... We would like the community to review this document. Although this is not a formal policy proposal, we would like to issue a 4 week working group last call on this draft before publication. Minor changes like typos or formatting can be sent to the authors or to me directly. Please raise any questions or comments on the content to this list. Unless blocking issues are found on this text, it is our intent to publish this draft as a RIPE Document and to change the status of the current document ripe-501 to obsolete, with a reference to the new document. The authors will also present on this draft during the IPv6 working group session at the Vienna meeting. Please send any comments before Thursday November 10 2011, which is 4 weeks from now. Regards, Marco Hogewoning on behalf of the IPv6 Working Group chairs
Hi all, I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346. Besides updating the list, do you find it appropriate to include RFCs with experimental status? Also 3484bis is still in draft. If we include drafts, then 6204 should also be changed to 6204bis. Although i would prefer to have the final RFCs in. -- Tassos Marco Hogewoning wrote on 13/10/2011 12:15:
Dear colleagues,
Following up on feedback received from the community during and after the publication of the ripe-501. The authors have worked on a replacement document, incorporating suggestions made by the community and clarifying some of the requirements. Prior draft versions of this document have been posted to this mailing list in the past months.
The resulting final draft document is now published on the website and reachable via https://www.ripe.net/ripe/docs/other-documents/requirements-for-ipv6-in-ict-...
We would like the community to review this document. Although this is not a formal policy proposal, we would like to issue a 4 week working group last call on this draft before publication.
Minor changes like typos or formatting can be sent to the authors or to me directly. Please raise any questions or comments on the content to this list. Unless blocking issues are found on this text, it is our intent to publish this draft as a RIPE Document and to change the status of the current document ripe-501 to obsolete, with a reference to the new document.
The authors will also present on this draft during the IPv6 working group session at the Vienna meeting.
Please send any comments before Thursday November 10 2011, which is 4 weeks from now.
Regards,
Marco Hogewoning on behalf of the IPv6 Working Group chairs
Tassos,
I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346. Besides updating the list, do you find it appropriate to include RFCs with experimental status?
I think we should apply reasonable judgement. with regards to A+P, that's an architecture document. I don't understand how an implementation could support that. there are a number of A+P-ish solutions being worked on in the softwire wg. 4rd, dIVI and ds-lite + A+P. plus a general stateless address mapping document and DHCP option. these are the A+P solutions, but way too early to include any of this work. I do not think 6346 belongs in RIPE-501.
Also 3484bis is still in draft.
3484bis fixes some real problems. hopefully it will be RFC before 501 is out.
If we include drafts, then 6204 should also be changed to 6204bis. Although i would prefer to have the final RFCs in.
I have suggested to just shelf 6204bis until we have something to put in it. 501 already has the references to 6rd and ds-lite that 6204bis adds. so not needed. cheers, Ole
Also keep in mind that RIPE-501(bis) addresses a very specific need: helping IT managers select the best real-life IPv6-capable equipment. We could put together the best list of RFCs and drafts, but if nobody supports them (and thus an IT manager using RIPE-501bis cannot buy the boxes he needs), we've just shot ourselves in the foot ... unless you word the document in a way that says RFC-xxxx is mandatory, but RFC-yyyy is highly recommended as its replacement and brings you bonus points. Just my €0.0002 Ivan
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Ole Troan Sent: Friday, October 21, 2011 10:02 AM To: Tassos Chatzithomaoglou Cc: Marco Hogewoning; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment"
[...]
Also 3484bis is still in draft.
3484bis fixes some real problems. hopefully it will be RFC before 501 is out.
On 10/21/11 10:32 AM, Ivan Pepelnjak wrote:
Also keep in mind that RIPE-501(bis) addresses a very specific need: helping IT managers select the best real-life IPv6-capable equipment.
Hi, Indeed. That's the intention :)
We could put together the best list of RFCs and drafts, but if nobody supports them (and thus an IT manager using RIPE-501bis cannot buy the boxes he needs), we've just shot ourselves in the foot ... unless you word the document in a way that says RFC-xxxx is mandatory, but RFC-yyyy is highly recommended as its replacement and brings you bonus points.
I think it is that way (as we already had this discussion in the past)... Well established RFC is mandatory, "upgrade" optional - so I like to think :) /jan
On 10/21/11 10:01 AM, Ole Troan wrote:
Tassos,
I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346. Besides updating the list, do you find it appropriate to include RFCs with experimental status?
I think we should apply reasonable judgement.
with regards to A+P, that's an architecture document. I don't understand how an implementation could support that. there are a number of A+P-ish solutions being worked on in the softwire wg. 4rd, dIVI and ds-lite + A+P. plus a general stateless address mapping document and DHCP option. these are the A+P solutions, but way too early to include any of this work. I do not think 6346 belongs in RIPE-501.
hey, it's optional and covers everything you just said. Cool, is it? :)
Also 3484bis is still in draft.
3484bis fixes some real problems. hopefully it will be RFC before 501 is out.
early november?
If we include drafts, then 6204 should also be changed to 6204bis. Although i would prefer to have the final RFCs in.
I have suggested to just shelf 6204bis until we have something to put in it. 501 already has the references to 6rd and ds-lite that 6204bis adds. so not needed.
+1 /jan
I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346.
I think that is an easy fix when we publish it. Unless somebody has big objections against this change, we'll change the reference to point to the RFC instead of the draft. Marco
On 10/20/11 8:22 PM, Tassos Chatzithomaoglou wrote:
Hi all,
I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346.
Hi, Sorry for late response. I thought I updated that (as co-author of that RFC it is expected to be aware of that change :) ) but it looks like it got lost between the versions somewhere. I suggest we corect that in final version.
Besides updating the list, do you find it appropriate to include RFCs with experimental status?
Why not? I agree not putting it into mandatory, but it could stay as optional, specially because it's architecture RFC and covers many flavors of A+P :)
Also 3484bis is still in draft. If we include drafts, then 6204 should also be changed to 6204bis. Although i would prefer to have the final RFCs in.
No, drafts are probably not ok. /jan
A couple of late comments: - for host: I am not sure whether IKE/IPsec should be mandatory, this is not always the case NOW and the IETF intends to move this requirement to SHOULD rather than MUST - for host: I would add 'support ingress traffic filters if ingress traffic filters exist for IPv4' - consumer grade switches: AFAIK, those cheap switches do not support IGMP snooping, so, why mandating MLD snooping? - router and RFC 4213, only the dual-stack part should be supported (as none of us (?) loves tunnels), then the point after (IPsec for tunnels) becomes irrelevant as well as RFC 2473 - router: I would regroup MLD related in one line RFC 4541 (only when switching is implemented as it has no sense for a pure layer-3) and RFC 3810 - router: do we want to have privacy extension for routers as well? Even as an option? - router: I would move the /127 to the mandatory part - router: can we mandate the uRPF function (anti-spoofing?) - firewall & co: I would not mandate (optional is ok of course) to inspect protocol-41 packets for tunnels (because what about teredo? Or any other covert channels) - firewall & co: support of RFC 4213 should be mandatory for the dual-stack part, I cannot imagine having a firewall doing encapsulation (option ok of course) - firewall: mandatory stateful inspection of application traffic transported above IPv6 is the same application is inspected over IPv4 - load balancers: I would put perhaps a gradation in the different 4-6 6-4 load-balancing - load balancers: I fail to see why ISAKMP should be mandatory esp. when IPsec is optional :-) Hope this helps even if a little late... -éric
-----Original Message----- From: ipv6-wg-bounces@ripe.net [mailto:ipv6-wg-bounces@ripe.net] On Behalf Of Marco Hogewoning Sent: jeudi 13 octobre 2011 11:16 To: ipv6-wg@ripe.net Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirementsfor IPv6 in ICT equipment"
Dear colleagues,
Following up on feedback received from the community during and after the publication of the ripe-501. The authors have worked on a replacement document, incorporating suggestions made by the community and clarifying some of the requirements. Prior draft versions of this document have been posted to this mailing list in the past months.
The resulting final draft document is now published on the website and reachable via https://www.ripe.net/ripe/docs/other-documents/requirements- for-ipv6-in-ict-equipment
We would like the community to review this document. Although this is not a formal policy proposal, we would like to issue a 4 week working group last call on this draft before publication.
Minor changes like typos or formatting can be sent to the authors or to me directly. Please raise any questions or comments on the content to this list. Unless blocking issues are found on this text, it is our intent to publish this draft as a RIPE Document and to change the status of the current document ripe-501 to obsolete, with a reference to the new document.
The authors will also present on this draft during the IPv6 working group session at the Vienna meeting.
Please send any comments before Thursday November 10 2011, which is 4 weeks from now.
Regards,
Marco Hogewoning on behalf of the IPv6 Working Group chairs
Hi Eric,
- for host: I am not sure whether IKE/IPsec should be mandatory, this is not always the case NOW and the IETF intends to move this requirement to SHOULD rather than MUST
I agree that we should follow the IETF in this.
- for host: I would add 'support ingress traffic filters if ingress traffic filters exist for IPv4'
+1
- consumer grade switches: AFAIK, those cheap switches do not support IGMP snooping, so, why mandating MLD snooping?
I agree. A switch that doesn't do IGMP snooping should not have to do MLD snooping...
- router and RFC 4213, only the dual-stack part should be supported (as none of us (?) loves tunnels), then the point after (IPsec for tunnels) becomes irrelevant as well as RFC 2473 - router: I would regroup MLD related in one line RFC 4541 (only when switching is implemented as it has no sense for a pure layer-3) and RFC 3810
Ok
- router: do we want to have privacy extension for routers as well? Even as an option? - router: I would move the /127 to the mandatory part - router: can we mandate the uRPF function (anti-spoofing?)
- firewall & co: I would not mandate (optional is ok of course) to inspect protocol-41 packets for tunnels (because what about teredo? Or any other covert channels)
I think it is wise to inspect everything that they can inspect. Protecting against covert channels is orthogonal to proto-41 inspection IMHO.
- firewall & co: support of RFC 4213 should be mandatory for the dual-stack part, I cannot imagine having a firewall doing encapsulation (option ok of course)
My Juniper SSG and SRX boxes do encapsulation...
- firewall: mandatory stateful inspection of application traffic transported above IPv6 is the same application is inspected over IPv4
+1
- load balancers: I would put perhaps a gradation in the different 4-6 6-4 load-balancing - load balancers: I fail to see why ISAKMP should be mandatory esp. when IPsec is optional :-)
Ack.
Hope this helps even if a little late...
Thanks for your feedback Eric :-) Sander
[apologies for being late] Dear colleagues, As I already posted to this list last week in another thread, the authors have decided to incorporate some of the comments received during the last call. Which means that at this point we can not declare rough consensus on this document. We've asked the authors to discuss the requested changes with the community and produce a new draft, which when ready will be offered to this working group for acceptance. If you need a profile for IPv6 requirements, for now please keep referring to document ripe-501 (http://www.ripe.net/ripe/docs/ripe-501). We would like to thank all of those who contributed both on this list and in private conversations, Greetings, Marco Hogewoning On Oct 13, 2011, at 11:15 AM, Marco Hogewoning wrote:
Dear colleagues,
Following up on feedback received from the community during and after the publication of the ripe-501. The authors have worked on a replacement document, incorporating suggestions made by the community and clarifying some of the requirements. Prior draft versions of this document have been posted to this mailing list in the past months.
The resulting final draft document is now published on the website and reachable via https://www.ripe.net/ripe/docs/other-documents/requirements-for-ipv6-in-ict-...
We would like the community to review this document. Although this is not a formal policy proposal, we would like to issue a 4 week working group last call on this draft before publication.
Minor changes like typos or formatting can be sent to the authors or to me directly. Please raise any questions or comments on the content to this list. Unless blocking issues are found on this text, it is our intent to publish this draft as a RIPE Document and to change the status of the current document ripe-501 to obsolete, with a reference to the new document.
The authors will also present on this draft during the IPv6 working group session at the Vienna meeting.
Please send any comments before Thursday November 10 2011, which is 4 weeks from now.
Regards,
Marco Hogewoning on behalf of the IPv6 Working Group chairs
participants (7)
-
Eric Vyncke (evyncke) -
Ivan Pepelnjak -
Jan Zorz ＠ go6.si -
Marco Hogewoning -
Ole Troan -
Sander Steffann -
Tassos Chatzithomaoglou