- lir-wg - mailman.ripe.net

Re: [lir-wg] AS Number Policy
by Hank Nussbacher 10 Jul '02

10 Jul '02

On Tue, 9 Jul 2002, Christopher Sharp wrote: > On Tue, 09 Jul 2002 12:57:46 +0300, Hank Nussbacher <hank(a)att.net.il> wrote: > > >At 11:53 AM 09-07-02 +0200, leo vegoda wrote: > >>1. How long does the community believe it is reasonable to take to > >> bring an AS 'on-line'? > >3 months. > > > >>2. After how many months of not being in use should an AS be > >> returned? > >3 months. > > > >3.After how many months of being single-homed should an AS be returned? > >9-12 months. > > I agree with the time scales for unused ASes and think Hank has raised a very > valid point about those in use.I would be in favour of a 6 month timescale for > return of these 'unless intent can be proven to re-multi-home within 3 months'. > > Producing an easily enforceable policy covering those AS in use may be a little > more complicated.I think most offenders who have become single-homed are > likely to ignore warnings of an approaching return date until it arrives.I > suggest a 6 month period of warning followed by a formal request for return and > a 3 months for them to depreciate use of the AS and return it.The net result > is a 9 month period of return with plenty of warning to depreciate use of a > single-homed AS. > > C. > The problem I foresee will be removing an ASN. RIPE has a policy of not changing mntner objects or overriding them so if the ASN just ignores RIPEs emails and continues to use the ASN - then what? And even if RIPE manages to have a procedure for removing an ASN against the will of the organization it was allocated to, what is to stop the organization to continue to use it? Those that follow NANOG have seen a case of AS5757 which is not listed in any DB and it has been announced for the past 3 years. Hank Nussbacher

5 7

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 10 Jul '02

10 Jul '02

>Again - what is the reason in using AS numbers from PUBLIC pool for >customer's ASes if this ASes will never appear outside of upstream ISP >network? How do you define "never" in today's or tomorrow's Internet ?! ;-) -w

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 09 Jul '02

09 Jul '02

This has nothing to do with the private AS-number. If an AS number existed in our backbone (public to CW) but not to RIPE NCC's route server. Will that be considered NOT USED ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Wolfgang Tremmel, WT5-RIPE [mailto:wtremmel@vianetworks.com] > Sent: Tuesday, July 09, 2002 1:27 PM > To: Lu, Ping; 'Matthew Robinson'; Vladimir A. Jakovenko > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: RE: [lir-wg] AS Number Policy > > > If it is nowhere advertised you could use a privat AS-number... > > Wolfgang > > > > -----Original Message----- > > From: owner-lir-wg(a)ripe.net > [mailto:owner-lir-wg@ripe.net]On Behalf Of > > Lu, Ping > > Sent: Tuesday, July 09, 2002 6:55 PM > > To: 'Matthew Robinson'; Vladimir A. Jakovenko > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > > Subject: RE: [lir-wg] AS Number Policy > > > > > > Definitely there is AS number being used within our backbone but not > > advertised to public > > network. So the AS number should be allowed to be registered but not > > advertised the same way > > as IP address is treated. > > > > Ping Lu > > Cable & Wireless USA > > Network Tools and Analysis Group > > W: +1-703-292-2359 > > E: plu(a)cw.net > > > > > > > > > -----Original Message----- > > > From: Matthew Robinson [mailto:matthew@crescent.org.uk] > > > Sent: Tuesday, July 09, 2002 9:57 AM > > > To: Vladimir A. Jakovenko > > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > > > Subject: Re: [lir-wg] AS Number Policy > > > > > > > > > In the documentation for address space provision is made for > > > assigning addresses to organisations that will NEVER be > > > connected to the Internet but require uniqueness from private > > > address space. > > > > > > Whilst I can't think of a specific example to apply to AS > > > numbers, should this uniqueness be extended to AS numbers > > > that do not show up in the routing table but are very > much on-line? > > > > > > I also recon 3 months to get online although given the length > > > of time it can take a big comapany to integrate a small one > > > lets say 12 months for returning. > > > > > > Kind regards > > > > > > Matthew > > > >

2 1

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 09 Jul '02

09 Jul '02

Beri, I agree with most of your statements, in particular your assessment of the "credibility" of RIS data *) to base such important decisions on - as well as the suggestion to accept a "statement of use" as sufficient. However, doing so leaves me with a cost vs. benefit ratio for the whole exercise! I guess there is a considerably big number of AS#s the RIR/LIR tree does not have authority over (or rather: distribution predating existence of those structures). And, unless we have a _clear consensus_ that going through this exercise can avoid the introduction of AS#s with more than 16 bits _altogether_ (or at least extends the lifetime of the 16bit version *considerably*), the whole issue might be mute... Wilfried. *) this is not questioning the usefulness or utility of RIS data, but it seems to be the wrong tool for obtaining a reliable reading for this context. And I guess it's pretty easy to fake... ______________________________________________________________________ Date: Tue, 9 Jul 2002 15:33:53 +0200 (CEST) From: Berislav Todorovic <beri(a)kpnqwest.net> To: leo vegoda <leo(a)ripe.net> CC: lir-wg(a)ripe.net Subject: Re: [lir-wg] AS Number Policy On Tue, 9 Jul 2002, leo vegoda wrote: >> We would be grateful if the community would clarify the policy so >> that it is clear when an unused AS number should be returned to >> the pool. Let's try to summarize things a bit: this issue is not only about numbers and timescale. A complete AS number revokation policy must comprise of 4 components: * Audit policy on AS number usage. * Clear definition of policy violation. * Revoking AS numbers from customers violating AS number usage policies. * Reusing revoked AS numbers. RIPE NCC reserves the right to perform periodic audits on AS number usage and take appropriate actions if necessary, to enforce compliance with ripe-245 and RFC 1930. RIPE NCC will use RIS to check if an AS number is used with compliance with those documents. RIPE NCC must never consider RIS as the ultimate source and must always raise an audit ticket towards the LIR and/or an end customer of an AS before taking any further action. A possible violation of the policy happens if an AS number: (1) Does not appear in the routing table at all: (a) Assigned, but never appeared (startup case) within S months. (b) Missing completely for more than D months. (2) Appears in the routing table via a single AS path for more than M months. While we can discuss on the values of S, D and M special care must be taken on revokation and reusal policy. For (1a) - there seems to be a consensus that S would be 3 months. For (1b) - just to be on the safe side D should be at least 6 months. For (2) - also to be on the safe side M should be at least 12 months. If a violation if found, RIPE NCC reserves the right to notify the LIR that requested the AS number about violation and ask them to provide additional evidence that the AS number is still in valid use. A clear statement from the LIR that the AS number is still used in compliance with the policy MUST be enough to close the audit ticket. No further action should be taken in that case. If there is no response from the LIR, RIPE NCC should contact the admin-c and tech-c specified in the aut-num object. In a lot of cases an AS number is issued by a LIR that doesn't have anything to do with the customer any more. If no response counting from notification date is received from the end customer: * In the case (1a) - within 3 months, * In the case (1b) - within 6 months, * In the case (2) - within 12 months the AS number may be revoked by RIPE NCC. AS number reusage policy - a revoked AS number may be reused after certain period of time, defined as: * In the case (1a) - 3 months after it is revoked from the end customer. * In the case (1b) - same time period that elapsed between revokation date and initial assignment date of the AS number. That should give enough time to all people to cleanup their configurations, policies etc. * In the case (2) - same as (1b). Regards, Beri --------------------------------------------------------------------------------

1 0

AS Number Policy
by leo vegoda 09 Jul '02

09 Jul '02

Dear Colleagues, Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool. We would be grateful if the community would clarify the policy so that it is clear when an unused AS number should be returned to the pool. Specific questions we would like to ask are: 1. How long does the community believe it is reasonable to take to bring an AS 'on-line'? 2. After how many months of not being in use should an AS be returned? Due to a lack of time in the LIR Working Group session at RIPE 42 (May 2002) we were not able to discuss the community's policy for AS numbers. We would like to raise the issue now so that there is ample time for a discussion before RIPE 43, on Rhodes, in September. We welcome the community's input on this policy matter. Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

7 7

RE: [lir-wg] Discussion Summary: Status field for inet6num object s
by Guy Davies 08 Jul '02

08 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would prefer RIR-LIR-ALLOCATED, LIR-SUB-ALLOCATED and LIR-USER-ASSIGNED (or similar) if we must keep ALLOCATED and ASSIGNED in the descriptions. I don't think that it is immediately clear from the proposals below whether LIR-ALLOCATED is allocated by an LIR or to an LIR. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, July 08, 2002 1:42 PM > To: leo vegoda > Cc: ipv6-wg(a)ripe.net; lir-wg(a)ripe.net; db-wg(a)ripe.net; > sig-db(a)apnic.net; > policy-db(a)apnic.net; apnic-talk(a)apnic.net > Subject: Re: [lir-wg] Discussion Summary: Status field for inet6num > objects > > > Hi, > > On Mon, Jul 01, 2002 at 06:21:24PM +0200, leo vegoda wrote: > > The RIPE NCC needs to implement a new status attribute for the > > inet6num object to reflect the new policy agreed by the RIPE, > > ARIN and APNIC communities. > > > > The RIPE NCC suggested the following new status attributes for > > the inet6num objects: > > > > - RIR-ALLOCATED > > (For allocations made by an RIR to an LIR) > > > > - LIR-ALLOCATED > > (For allocations made by an LIR or an LIR's downstream > > customer > > to another downstream organisation) > > > > - ASSIGNED > > (For assignments made to End User sites) > > I haven't seen any replies to this so far. > > I want to express that I like this proposal. It doesn't introduce > any new and yet-undefined terms, but makes clear what the status of > a given network is. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: > 45809 (45931) > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPSmLLo3dwu/Ss2PCEQIJdQCeOKDqqTLKCuB+o3pWMj/XJ41QJMQAnROW EWRBiRI4rPpF9DRbhrxYcK0S =Rab7 -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

2 1

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

6 8

New Document available: RIPE-244
by RIPE NCC Document Announcement Service 05 Jul '02

05 Jul '02

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-244 Title: Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region Author: Joao Luis Silva Damas, Leo Vegoda Date: 4 July 2002 Format: PS=13515 TXT=4723 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the policy for reverse delegation of IPv4 assignments and allocations in the RIPE NCC service region. Accessing the RIPE document store --------------------------------- You can access the "Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region" in HTML format at the following URL: http://www.ripe.net/ripe/docs/rev-del.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-244.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-244.txt plain text version

2 1

New IPv6 policy implemented on 1 July 2002
by Paul Rendek 01 Jul '02

01 Jul '02

Dear Colleagues, The RIPE NCC is pleased to announce the implementation of the new IPv6 policy effective 1 July 2002. This IPv6 policy was accepted by consensus at RIPE 42 and is common to all Regional Internet Registry communities - APNIC, ARIN, and the RIPE NCC. The new policy replaces the provisional IPv6 policy launched in 1999. The IPv6 Policy documentation is available from the RIPE document store at: http://www.ripe.net/ripe/docs/internet-registries.html The current set of IPv6 documents are: - IPv6 Address Allocation and Assignment Policy - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - Supporting Notes for the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region - Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Key points of the new IPv6 policy you should be aware of: - The minimum allocation size is /32; - LIRs currently holding a /35 have the option of expanding their allocation to a /32 on request; - In 2002, no additional fees are charged for IPv6 address space in the RIPE NCC service region. The RIPE NCC IPv6 web pages can be found at: http://www.ripe.net/IPv6/ Regards, Paul Rendek Communications Manager RIPE NCC

2 1

Re: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder
by Janos Zsako 28 Jun '02

28 Jun '02

> From owner-lir-wg(a)ripe.net Thu Jun 20 12:15:28 2002 > From: Paul Rendek <ncc(a)ripe.net> Dear all, > This is a reminder that the deadline for comments and suggestions for the > draft in-addr policy document is set for Monday, 24 June 2002. The new > draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC > Service Region" document can be found on our website at: > > http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume… > > All comments and suggestions should be sent to <lir-wg(a)ripe.net>. I would have a short question and a suggestion for clarification. 1. Is the last paragraph of 3.0 not superfluous in the light of the last paragraph of 5.0? 3.0: "LIRs should maintain DNS resource records for address space assigned to End Users from their own address space, even if the user obtains connectivity from a different LIR." 5.0: "LIRs should provide reverse delegation corresponding to an assignment during the complete validity period of the assignment." I mean that my understanding is that for 3.0 there are two cases: the end-user either _changes_ its provider, in which case they will have to renumber, and during renumbering their assignment is valid, i.e. the old LIR has to provide reverse DNS according to 5.0 during renumbering, or the end-user becomes multi-homed, therefore they will keep the old address space for which they obviously will need reverse DNS (on the long run) that the old LIR is again supposed to provide, based on 5.0. Am I missing something? 2. I think the intent of first paragraph of 3.0 is to accept a reverse delegation of an address block as soon as there is ANY address space assigned from it (i.e not ALL has to be assigned prior to reverse delegation), assuming that the whole block has been allocated to that LIR (this is relevant only for /16s). Therfore I suggest something like: "The RIPE NCC accepts requests for reverse delegation solely for address space that HAD BEEN ALLOCATED TO THE REQUESTING LIR AND AT LEAST ONE PORTION OF WHICH has been registered by the LIR as assigned to End Users in the RIPE Whois Database." (You will probably find a better word than "portion" to describe this). Best regards, Janos

2 1