- BCOP - mailman.ripe.net

IPv6 prefix delegation BCOP document available for comments and suggestions
by Jan Zorz - Go6 03 Apr '17

03 Apr '17

Dear RIPE BCOP community, As promised at last RIPE meeting in Madrid, we produced a first draft of "Best Current Operational Practice for operators: IPv6 prefix assignment for end-users - static (stable) or dynamic (non-stable) and what size to choose." The aim of this document is to document the best current operational practice on what size of IPv6 prefix ISPs should assign/delegate to their customers and should they delegate it in a stable, static way or should it change over time. Please find the PDF attached and also accessible at: https://www.sinog.si/docs/draft-IPv6pd-BCOP-v1.pdf We are submitting this document to RIPE BCOP TF (here) to check if this is a real best operational practice and get consensus on it. We are also submitting this document to RIPE IPv6 WG to check the technical validity of the document and also get consensus on it. Please, read the document and send back comments to this mailing list. All feedback is more than welcome. On behalf of co-authors, Jan Žorž P.S: This document is not intended to document what practices may be in future and what they might look like, but to reflect the best methods of implementing IPv6 at the time of publication. Updates to this document will be published to reflect changes in best current practices where there are developments in standards and implementations.

5 7

Mutually beneficial or altruistic?
by Steve Nash 19 Jan '17

19 Jan '17

Some thoughts on BCOP TF objectives. The current statements of BCOP TF Charter and activities do not make distinctions between Practices that are good for the Internet (mutually beneficial) and Practices that are good recommendations for the individual Operator (altruistic). MANRS clearly sits in the former, but does contain some altruistic recommendations also. I suggest that the BCOP TF charter should be clarified to state clearly whether its scope is solely BCOPs that are mutually beneficial. There seem to me to be a lot of opportunities for more altruistic output, but these are not being discussed. I happen to be employed by Arbor Networks so I hear a lot about bad things that happen across the Internet. Considerations for BCOPs that could be worked on: * Amplification attacks. Avoid being an Amplifier. Do not respond to connectionless service requests from outside of your own address space. DNS, NTP, Chargen... Configure your servers and ingress filters accordingly. (mutually beneficial) * For Internet Access providers, consider offering, as the default entry level Internet Access Service, something which does not allow external DNS / NTP resolution, to limit some of the methods available to 'malware' that gets on to consumer systems. (mutually beneficial) * Implement a separate network for monitoring and managing your network. Otherwise, a large traffic anomaly, like a DoS attack, may flood your internal links and make your network invisible and uncontrollable. A physically separate network is best because virtual networks have to have classifiers that decide the priority/VLAN for arriving traffic and these can also be overwhelmed by large anomalies, with the same bad results. (altruistic) * When acquiring routers and networking equipment, pay attention to the need to monitor. Can a new device generate flow reports and process SNMP requests at useful rates without impairing your forwarding performance below the level you need? Be prepared for exceptional packet rates, not just bit rates. (altruistic) * Discuss Flowspec opportunities with your peers and transit providers to give yourself as many opportunities as possible for traffic engineering to achieve mitigation. (altruistic) * Customer contracts and DoS attacks. Make it clear that the customer is contracting to receive a limited amount of bandwidth (and packet rate). If they attract a higher rate of traffic, the ISP will HAVE to drop some traffic randomly, and may need to drop all traffic to protect its other customers. Consider offering mitigation services to customers that wish to protect themselves against these incidents. (altruistic) * Customers that have totally free access to the Internet represent additional risk to you, the ISP. For customers that want the full experience, cover your additional risk mitigation costs. (altruistic) Regards Steve

3 3

Fwd: Re: Last Call: MANRS BCOP document
by Andrei Robachevsky 28 Nov '16

28 Nov '16

[Forwarding it as I am not sure it got through] -------- Forwarded Message -------- Subject: Re: [bcop] Last Call: MANRS BCOP document Date: Mon, 28 Nov 2016 18:33:50 +0100 From: Massimiliano Stucchi <mstucchi(a)ripe.net> Reply-To: mstucchi(a)ripe.net Organisation: RIPE NCC To: bcop(a)ripe.net Hi, On 31/10/16 17:38, Andrei Robachevsky wrote: > As agreed at the RIPE BCOP TF meeting last week, here is a last call for > the review of the MANRS BCOP document. This last call ends on November > 28, 2016. > > The document is available here: http://tinyurl.com/jlulren I'm sorry if I write on the very last day of the last call period. We as Training Services were recently approached by Andrei about this document as part of a broader project to collaborate on some topics. I read through it and have some suggestions on how to improve it. I had not had time before to read it, so some of the suggestions come from a fresh reader that saw the text for the first time. We do mention it already in our BGP and routing security training course (https://www.ripe.net/support/training/courses/bgp) and I'm sure we are going to add more details as the document will be officially published. I really think we needed something like this, and I'm sure we are going to add it to the material we distribute with our BGP and routing security training course, as it perfectly rounds what we teach there in a nice and concise way, good for both newcomers and experts. So, here are some suggestions for improvements: - Section 4.1.1.2, second paragraph: I would change from the second sentence with "The advantage of using a ROLE object is that, while people can change jobs and move to a different organisation, a department or role does not change. A ROLE object can, in fact, optionally refer to other PERSON objects, adding information about contact persons for a specific group or department"; - In the following example, I would add some admin-c and tech-c attributes as examples, with a description of what they do and the differences between them; - On a related note, it would allow to build a whole chain with the following example of inet6num. After that, then I would take a paragraph to discuss the relationships with all the objects, then (I mean the chain between person-->role-->inet6num, and their roles with abuse handling as well); - The second paragraph after the inet6num example is no more correct. The database recently changed so that every LIR has its own maintainer set also for allocations, together with RIPE-NCC-HM-MNT. This means that changes can be made to an allocation inet{,6}num directly into the database. Business rules are going to restrict what you - as an LIR - can change, though; - Section 4.1.5: At the end of the first paragraph there's a double "and"; - Same section, at point 2-C, I think the sentence needs to be finished. I think we're missing "the ASN in the database", but I could be wrong here; - Section 4.2: At the first bullet point, I would add a semicolon instead of a full stop; - I would change the second paragraph in the same section to something like this: "Routing information should be made available on a global scale to facilitate validation. This includes routing policy, ASNs and prefix that are intended to be advertised to third parties. Since the extent of the internet is global, information should be made public and published in a well known place using a common format." - I would also change the following paragraph to something like this: "MANRS participants should maintain public information updated in order to facilitate the validation of routing information. This includes the following data:" - I would change the first paragraph in section 4.2.1 to something like this: "The goal of Origin validation is to verify that the rightmost - also called the originator - ASN in an AS_PATH is correct. This can be verified by correlating address space (or prefixes) and ASNs. To facilitate this, all MANRS participants should make these information available publicly in database such as the IRRs. They should also encourage their IP transit customers to do the same for their own address space."; - Section 4.2.1.2: In the first paragraph, I would suggest we say "The RPKI repository can store information about prefixes originated by your network in _the_ form of ..."; - Section 4.2.1.2.3: I would eliminate the first "of" in the first sentence; - In the same paragraph, last sentence, I would change the sentence like this: "... or customers that received address their address space as an assignment from their provider, ..."; - In the following paragraph: "Establish a process that ensures that every time you originate _a_ new prefix from your network, ..." and "This should become a a normal process integrated in your NOCs procedures" as last sentence; - In section 4.2.2.1, I would put an example of an AS-SET. This is not discussed anywhere, so I would also be happy to provide some info if we decide it's worth to have it there; - After the routing policy example, I would change the wording in the first paragraph to this: "as-set and other object sets derived from _an_ AS Policy documentation and then..."; - In the following paragraph, I would change the first "can" with "could"; - Section 4.3, 3rd paragraph: I would the wording into this: "Since 2005, deployment of anti-spoofing techniques _has_ not been a limitation ..."; - I would change the beginning of the following paragraph into this: "Ironically, significant DoS amplification attacks can be expensive for Service Providers."; - In paragraph 5, I would change "... there are no benefits to a service provider ..." into "... there are no benefits for a service provider ..."; - In paragraph 6: "These methods can ease the overhead of administration in cases where routing and topology _are_ relatively dynamic."; - In section 4.3.2, I think we should add a description of how feasible path works, even if we decide to keep it small and concise; - I noticed we should make the use of ASN or ASes consistent accross the document. It's spelled in different ways all over. This is something for the final review, though; - Section 4.4, second bullet point: I would change "their" into "its"; - Section 4.4, 5th paragraph: "... provided by the customer about their identity and resources _are_ correct"; - Section 4.4, 7th paragraph: " ... or fully validated _against_ the entire ordered set ..."; - Section 4.4, between the two example datasets: "And similar objects for their _other_ customer, AS64502"; - Section 4.4.1.2.1, last paragraph: "As you can see _in_ the IPv6 example ..."; - Section 4.4.1.2.2, first paragraph: "IRRPT generates prefix-lists just _like_ bgpq3 ..."; - Section 4.4.1.4, Delta checks: "Ensure that if a filter changes _by_ a delta ..."; - Section 4.4.2.1: Remove "it" from the first sentence; - Section 4.4.3, first paragraph: "For these purposes, a path is considered valid if it _is_ consistent with ..."; Sorry if this email looks pedantic, but I wanted to make sure we make a great document that can be used and distributed as much as possible, and so far we're on the right track! :) I'm available for any comment or to discuss any of my suggestions. Ciao! -- Massimiliano Stucchi RIPE NCC mstucchi(a)ripe.net Follow us on Twitter for the fastest and latest RIPE NCC Training news! @TrainingRIPENCC

1 0

Last Call: MANRS BCOP document
by Andrei Robachevsky 28 Nov '16

28 Nov '16

Hi, As agreed at the RIPE BCOP TF meeting last week, here is a last call for the review of the MANRS BCOP document. This last call ends on November 28, 2016. The document is available here: http://tinyurl.com/jlulren Regards, Andrei

2 1

IPv4 statement
by Sander Steffann 31 Oct '16

31 Oct '16

Hi, At the last RIPE meeting I tried to get community consensus on a statement to make it clear what the best way is to use the last remaining IPv4 addresses. Consensus in the plenary failed and the feedback I got was that we needed something stronger. And then I forgot about it... So far, I have come up with the following statement: """ It is important to realise that there isn't any IPv4 space left; the RIPE NCC has a small reserve to allow new members to get a /22 so they can start up a business, to bootstrap and to communicate with the legacy Internet. But this is not something anybody can build their future on. The only way to survive in the future is to implement IPv6 from the start. It is not sustainable to build an IPv4-only network anymore. The best current operational practice is to build IPv6 networks and have translation mechanisms to IPv4, and that is the only sustainable way forward. Anything else will require increasing investments in a declining technology. """ I think it's not good enough, but I lack inspiration to make it better. I would appreciate help from this task force. Cheers, Sander

3 2

BCOP TF meeting in Madrid (RIPE73)
by Jan Zorz - Go6 20 Oct '16

20 Oct '16

Dear BCOP community, We'll meet again in Madrid during the RIPE73 week, as usually on Monday after the plenary sessions are over. We have some new updates on the work that is being done, but we would like to ask also for some updates from all authors that are working on their documents for update and also for new ideas for BCOP documents. Please, be quick with suggestions as we have to publish the agenda soon. Cheers and thnx, Benno and Jan

2 1

Final draft of the MANRS BCOP document
by Andrei Robachevsky 18 Oct '16

18 Oct '16

Hi, The MANRS BCOP document is almost ready! Here it is: https://docs.google.com/document/d/1ZBIvtBQ-Fc4RZKXnOpEQIGJfxPr21brqqiYVRSa… It has been reviewed by several MANRS participating operators and the MANRS BCOP team. Sander Steffann took the editorial pen at the final stage of its production, added missing content and brushed it up. There is still room for improvement - and the review and feedback from this community will be very much appreciated. Please send your comments and suggestions. During RIP73 next week this document will be also discussed at the BCOP TF on Monday. If you plan to be at RIPE73, please join this session. We hope to finalize this work (this phase, at least) soon after RIPE73 and reference it from the BCOP repository. Regards, Andrei, on behalf of the MANRS BCOP team

2 1

iPad Air 2
by mostafa shahdadi 19 Aug '16

19 Aug '16

-- Sent from Gmail Mobile

1 0

an amazing article
by Andreas Jonsson 18 Aug '16

18 Aug '16

Hi! Have you read that article already? It's amazing, and I guess you'll love it, take a look <http://tyntyshody.bentrippin.com/e4fwddg> Warmly, Andreas Jonsson

1 0

Community statement
by Sander Steffann 30 May '16

30 May '16

Hi BCOP people, As I promised on Monday during the BCOP session at RIPE 72 I would prepare a community statement that reflect the wise words that our RIPE Chair, Hand Petter Holen, made at the opening ceremony. I discussed this with Hans Petter because I don't want to take someone else's words without permission. He was ok with using his words as the starting point and form a community statement in BCOP based on that. For reference here is the original transcript taken from https://ripe72.ripe.net/archives/steno/5/: > Now when that is said, it's always also important to realise that with IPv4 space, the legacy old IP addresses, there isn't anything left; we have a small reserve so new members can get a /22, as we call it, around a thousand addresses, so they can start up a business. But this is not things you can build your future on. The only way to survive in the future is to implement v6 from the start, then you can get some v4 addresses so you can boot strap and still be connected to the legacy Internet, but it is possible today to build v6 networks and have transition mechanisms to v4 and that is the only sustainable way going forward. As my intention is both making a clear statement about the Best Current Operational Practice on using the last remaining IPv4 addresses, and to show confirmation as a community that we stand behind the statement from our RIPE chair I have stayed as close to this original as possible. I have reorganised it a bit to make it easier to read, and I propose that we bring the following text to the floor on Friday: ------------- It is important to realise that there isn't any IPv4 space left; the RIPE NCC has a small reserve so new members can get a /22 so they can start up a business, to bootstrap and to communicate with the legacy Internet. But this is not something anybody can build their future on. The only way to survive in the future is to implement IPv6 from the start. It is possible to build IPv6 networks today and have transition mechanisms to IPv4, and that is the only sustainable way forward. ------------- If this task force agrees on a text I will present it on Friday during the closing plenary and ask the community as a whole to express their support. Please let me know if you think the proposed text is indeed a BCOP and that it represents the words from Hans Petter correctly. Cheers, Sander

7 18

call for presentations RIPE 72 BCOP Task Force
by Benno Overeinder 17 May '16

17 May '16

Hi all, The draft agenda is just published, but we still have room for one contribution. You think some operational practices should be documented? Take the floor for a 10-15 minutes pitch and find other interested network engineers to work on a BCOP document! Drop me or Jan, or both, an email if you want to present your ideas. Best, Jan Zorz & Benno Overeinder -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

RIPE 72 BCOP Task Force draft agenda
by Benno Overeinder 17 May '16

17 May '16

Hi all, The RIPE 72 BCOP Task Force session is scheduled for Monday May 23th, 18:00-19:00. The draft agenda is: Where: Main room • A. Administrative Matters and Agenda Bashing [5 min], Benno and Jan • B. Report on what's going on in LAC and Africa region re BCOP [10 min], Jan Zorz • C. BCOP on DNS operations [15 min], Markus de Brün • D. MANRS BCOP update [15 min], Andrei Robachevsky and Job Snijders • E. Open Microphone Session: Ideas for New BCOPs and Volunteering We still have a slot available for pitching an idea on documenting best operational practices. See you in Copenhagen, Jan Zorz & Benno Overeinder -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

Re: [bcop] MANRS BCOP document
by Andrei Robachevsky 15 May '16

15 May '16

Colleagues, Following Job's presentation "MANRS Implementation Document" at the BCOP TF at RIPE71 last week (https://ripe71.ripe.net/programme/meeting-plan/bcop-tf/) we corralled a group of volunteers to move this project forward. Folks that agreed to help and share their experience are: Brian J. Foust, Aaron Hughes, Will van Gulik and Aris Lambrianidis. Thank you! Of course Job and I will continue to shoulder this effort. To continue discussions and produce a draft document for wider review we created a mailinglist: https://elists.isoc.org/mailman/listinfo/manrs-bcop. Feel free to subscribe if you are interested! Otherwise - stay tuned. Regards, Job and Andrei Job Snijders wrote on 29/10/15 17:41: > Hi all, > > We discussed this idea a few times before and I think agreed that it'd > be a good idea to have a more precise guidance for the implementation of > MANRS Actions. > > As I can see, it will serve at least two purposes: > > - Ease deployment of measures required by MANRS (we are talking here > about stub networks or small providers - the majority of ASNs) > - Help checking if the network setup is compliant with MANRS > > From my discussions with operators at various meetings where Andrei > Robachevsky presented MANRS it was also quite clear that such guidance > for the MANRS "package" would be appreciated, also to be able to assess > what it takes to become MANRS-compliant. > > So, Andrei and I took a stab at an outline of such document. It really > has only a structure and is lacking content with examples, etc. at the > moment. Help is needed! > > We put it as a Google doc, all of you should be able to edit it, so > please help with some stuff. Even if it is a raw material - such input > would be appreciated. > > The document is here: > > https://docs.google.com/document/d/1FQAVawGGvb-xqNLeGLk05h5nuu0FSS_9KLv6gBa… > > Kind regards, > > Job

1 1

MANRS BCOP Document
by Job Snijders 29 Oct '15

29 Oct '15

Hi all, We discussed this idea a few times before and I think agreed that it'd be a good idea to have a more precise guidance for the implementation of MANRS Actions. As I can see, it will serve at least two purposes: - Ease deployment of measures required by MANRS (we are talking here about stub networks or small providers - the majority of ASNs) - Help checking if the network setup is compliant with MANRS >From my discussions with operators at various meetings where Andrei Robachevsky presented MANRS it was also quite clear that such guidance for the MANRS "package" would be appreciated, also to be able to assess what it takes to become MANRS-compliant. So, Andrei and I took a stab at an outline of such document. It really has only a structure and is lacking content with examples, etc. at the moment. Help is needed! We put it as a Google doc, all of you should be able to edit it, so please help with some stuff. Even if it is a raw material - such input would be appreciated. The document is here: https://docs.google.com/document/d/1FQAVawGGvb-xqNLeGLk05h5nuu0FSS_9KLv6gBa… Kind regards, Job

1 0

Call for ideas and presentations for BCOP TF at RIPE71
by Jan Zorz 19 Oct '15

19 Oct '15

Dear BCOP community, RIPE71 is approaching rapidly and we would like to ask for some new ideas and presentations for BCOP TF meeting in Bucharest. Any volunteers that would like to start a new BCOP document? Please, respond to this list or to chairs directly. Cheers and see you all soon! Benno and Jan

1 0

BCOP Global Coordination meeting during the IETF93 in Prague
by Jan Zorz 16 Jul '15

16 Jul '15

Fellow RIPE BCOPers, I hope that summer is treating you all well ;) During the IETF93 meeting in Prague we'll have a BCOP Global coordination meeting on Sunday, 19th July in Budapest room, starting at 14:00 and finishing around 18:00. This meeting will bring together leaders of regional BCOP efforts and also other interest participants... If you are interested in the topic and you are in Prague for IETF (or other reasons) you are invited to join us. The topic of the meeting will be how to move forward the BCOP efforts around the world and to improve the coordination between them, as we start seeing some overlap in the work and proposed topics. If you plan to join us in discussion, please add your name to the Doodle poll: http://doodle.com/gbfwhqn8t8zxmnwk See you in Prague, Jan Zorz

1 0

BCOP Global Coordination meeting at IETF93 in Prague
by Jan Zorz - Go6 25 Jun '15

25 Jun '15

Dear RIPE BCOP community, After seeing some need for a bit of coordination between BCOP efforts around the world (some work is overlapping between the regions), we thought of setting up the BCOP Global coordination meeting just before IETF93 meeting in Prague. The BCOP GC meeting will take place on Sunday, 19th July 2015 at the IETF93 venue hotel Hilton in Prague. The room number/name is not set/known yet and it will be communicated when we receive this information. Of course, this is an open meeting to everyone interested in development of BCOP efforts and learning about what's going on at other regions. We need new ideas, new energy and a collective will to move and develop this initiatives further and get it off the ground for good - so everyone is invited to join and participate. As we need to anticipate the number of meeting attendees (to coordinate for the right size of the room), we would like you to add your name to Doodle poll: http://doodle.com/gbfwhqn8t8zxmnwk - or send an email to this list (or to Benno and/or myself if you wish). Everyone have a great summer and see you in Prague, Jan Zorz

1 1

BCOP TF meeting at RIPE70 in Amsterdam
by Jan Zorz ＠ go6.si 16 Apr '15

16 Apr '15

Dear BCOP community, RIPE70 is fast approaching and we would like to ask all fellow BCOP-ers to come forward if you have any updates on work done from previous meeting and also to present any new ideas that might emerge meantime on new BCOP documents that people wants to write and work on. As we saw there was some work on the list done for "IPv6 for small access providers" and we are not sure if this continued offline, nevertheless we encourage the authors to give us an update what's going on at the meeting. The same goes for all work that should be in progress - we would love to hear how things are progressing. Please send ideas/requests to this list or to Benno or myself directly, we need to put together an agenda for this upcoming meeting. See you in Amsterdam, Benno and Jan

1 0

Some test results and suggestions to IPv6 Troubleshooting
by 朱彥如 08 Apr '15

08 Apr '15

I have setup IPv6 environment and use test-v6.com to make some tests. I have some suggestions according to my test results: 1. In section 6, for the example result for “624-6to4”, I suggestion to use <2002:c000:0201::c000:0201> for the IPv6 address, instead of original <2001:db8::1>. <2002:c000:0201::c000:0201> is derived from “2002::/16+ <192.0.2.1>”, which I think is more easily understood by users. 2. In section 6, Interpretation for “624-6to4”, I have questions about the sentence: “Any web site that has an IPv6 presence, will be reached using 6to4 instead of native IPv4” I use win 7 with only IPv4 address configured, and thus 6to4 works. Then, I add an IPv6 default route to 6to4 relay router (anycast). The test result show that * IPv4 is preferred rather than Ipv6 6to4 (Only when connecting to IPv6-only servers, IPv6 6to4 will be used) * The test result of using test-v6.com show 624 (Help desk code) So, I think the interpretation does not match the real condition. The following is my test result and give you as a reference (if gif can be accepted and shown): [cid:image001.jpg@01D06BAB.3047DCE0] [cid:image002.png@01D06BAB.3047DCE0] Regards Yann-Ju ChungHwa Telecom. Co. Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

1 0

IPv6 troubleshooting for helpdesks document is now RIPE-631
by Jan Zorz ＠ go6.si 05 Mar '15

05 Mar '15

Dear RIPE BCOP community, With great pleasure we can announce that one of our first BCOPs in the works was few days ago published as RIPE-631 https://www.ripe.net/ripe/docs/ripe-631 Many thnx for all suggestions, comments and support during the work and I hope this document will be of much use to those operators, who are implementing IPv6 towards their residential customers (and also everyone else with similar task). With this document published I would like to encourage you all to continue the work on other documents that are currently active and also others, that we heard about during our last BCOP TF meeting. RIPE70 meeting in May is near and I hope for some advancement in all other documents in the queue so we can talk about some good stuff in Amsterdam! Cheers and thnx, Jan Zorz

1 0

Re: [bcop] IPv6 deployment for small residential providers
by d.baeza＠tvt-datos.es 04 Jan '15

04 Jan '15

Hi All, In what ended that? Regards, -Daniel > Just to follow up on the question I just asked following the BCOP > draft on troubleshooting IPv6 for residential providers, should we > write a companion document focused on small providers that explains > how to deploy IPv6? > > I am happy to start writing, would anyone like to help? > > Cheers, > -w

1 0

anti-spoofing document
by Mikael Abrahamsson 12 Nov '14

12 Nov '14

Hi, I keep running into people who have never heard of the excellent document that Torbjörn Eklöv has created over time. It came out of work to create requirements and certification for access networks, one large reason was to assure a secure end user connection that didn't have MITM and spoofing problems. The main site is here: http://secureenduserconnection.se/ Direct link to the current version of the document: http://secureenduserconnection.se/wp-content/uploads/2012/02/SEC-Secure-End… I recommend everybody looking for information and requirements on how to create a secure network to read this document. It's very comprehensive. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

3 2

IPv6 troubleshooting for helpdesk document - feedback from RIPE IPv6 WG
by Jan Zorz ＠ go6.si 12 Nov '14

12 Nov '14

Dear BCOP community, Just a heads-up - we presented this document at RIPE IPv6 WG, asking for technical feedback and after some discussion the co-chairs decided to open a 2 weeks window for the community to come back with any possible comments and then issue a last call. I think we should do the same here. I know there were no objections and good sense of support and consensus in the room, but if we are doing it in cooperation with other WGs, then we need to adapt with the timings. So, still time for last comments or feedback. https://www.ripe.net/ripe/groups/tf/bcop/ipv6-troubleshooting-for-residenti… Cheers and thnx, Jan Zorz

1 0

Re: [bcop] IPv6 deployment for small residential providers
by 马严 11 Nov '14

11 Nov '14

1 0

Re: [bcop] IPv6 deployment for small residential providers
by 马严 11 Nov '14

11 Nov '14

1 0