- BCOP - mailman.ripe.net

IPv6 prefix delegation BCOP document v.7
by Jan Zorz - Go6 21 Aug '17

21 Aug '17

Dear BCOP TF, Version 7 of IPv6 prefix delegation BCOP document was issued some time ago and I would like to propose that we move forward towards making this document a stable RIPE BCP document. https://www.sinog.si/docs/draft-IPv6pd-BCOP-v7.pdf We received quite a number of comments in RIPE IPv6 WG and now it seems that v.7 of the document is satisfactory enough (judging from lack of additional comments). Should we go forward and issue a week long last call and then try to move forward together with RIPE IPv6 WG and get a document number from RIPE NCC? Cheers, Jan

3 2

Version 6 of IPv6 prefix delegations BCOP is out
by Jan Zorz - Go6 08 Aug '17

08 Aug '17

Dear RIPE BCOP TF, We received offline some good and valuable comments from MarcoH, addressed them and issued the version 6 of the document draft. https://sinog.si/docs/draft-IPv6pd-BCOP-v6.pdf Please, read and comment, if you think that we need to carry on with editing this document. If not, I would like to see if we can reach a consensus to move forward and ask RIPE staff to do the language check and publish this document as RIPE BCP. Any comments? Suggestions? For v6_pd_BCOP co-authors team, Jan Žorž

1 0

IPv6 Prefix delegation BCOP version 3 is out...
by Jan Zorz - Go6 27 Jun '17

27 Jun '17

Dear RIPE BCOP TF, After presentation at RIPE74 BCOP TF and IPv6 WG sessions we got some feedback from community over mailing list and while on stage and we addressed those comments as far as we could, resulting in version 3 of the IPv6 prefix delegations draft. To avoid sending around emails with attachment I'm providing the link where you can access the PDF file: https://www.sinog.si/docs/draft-IPv6pd-BCOP-v3.pdf I have a feeling that after all this cycles and comments from the community - we are reaching the point when we'll have to consider calling a consensus if possible, make it a stable RIPE BCOP document and give it a number. Please, read the latest version and see if you can agree with the current text and express your support (if agree) on this mailing list, so chairs can judge if there is enough consensus on the text to maybe go into a TF last call (or maybe even skip that if clear consensus, this is not PDP process ;) ) Cheers and thnx, Jan (on behalf of the co-authors of the document)

2 1

FW: [ipv6-wg] IPv6 prefix delegation BCOP document - draft v.2 for review.
by JORDI PALET MARTINEZ 13 May '17

13 May '17

I just realized that this was not posted to the BCOP list … Inputs welcome! Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces(a)ripe.net> en nombre de Jan Zorz - Go6 <jan(a)go6.si> Responder a: <jan(a)go6.si> Fecha: jueves, 11 de mayo de 2017, 2:44 Para: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net> Asunto: [ipv6-wg] IPv6 prefix delegation BCOP document - draft v.2 for review. Dear RIPE IPv6 WG, As promised at BCOP TF meeting on Monday, the co-authors present at the RIPE74 meeting gathered on Tuesday afternoon and did some editorial work, addressing majority of the comments and suggestions we got from the community based on first version of the draft. Draft version 2 is now available for reading at https://sinog.si/docs/draft-IPv6pd-BCOP-v2.pdf We'll have a short "lightning talk" in Thursday IPv6 WG session, please go and read the document (those that have enough time and energy), so we get more feedback and input for further improvements (if needed). See you all in couple of hours! For co-authors team, Jan Žorž ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

BCOP TF meeting at RIPE74 in Budapest
by Jan Zorz - Go6 24 Apr '17

24 Apr '17

Dear BCOP community, In roughly two weeks we have a BCOP TF meeting in Budapest and we would like to ask if there are presentation proposals or new ideas for BCOP documents. If so, please send them to this list or the BCOP TF co-chairs (Benno and Jan) so we can put them on the agenda. See you all in Budapest, Jan

1 0

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