From ncc at ripe.net Mon Jul 1 10:31:29 2002 From: ncc at ripe.net (Paul Rendek) Date: Mon, 01 Jul 2002 10:31:29 +0200 Subject: [lir-wg] New IPv6 policy implemented on 1 July 2002 Message-ID: <5.1.0.14.2.20020701102711.00ae3c00@mailhost.ripe.net> 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 From ncc at ripe.net Mon Jul 1 10:31:29 2002 From: ncc at ripe.net (ncc at ripe.net) Date: Mon, 01 Jul 2002 10:31:29 +0200 Subject: [lir-wg] New IPv6 policy implemented on 1 July 2002 In-Reply-To: <5.1.0.14.2.20020701102711.00ae3c00@mailhost.ripe.net> References: <5.1.0.14.2.20020701102711.00ae3c00@mailhost.ripe.net> Message-ID: 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 From leo at ripe.net Mon Jul 1 18:21:24 2002 From: leo at ripe.net (leo vegoda) Date: Mon, 1 Jul 2002 18:21:24 +0200 Subject: [lir-wg] Discussion Summary: Status field for inet6num objects In-Reply-To: References: Message-ID: <20020701162124.GA23386@ripe.net> Dear Colleagues, 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) There was discussion as to whether the terms ALLOCATED and ASSIGNED should be used or whether DELEGATED was the preferred term. It was pointed out that changing the terminology would require a full rewrite of all documentation, web sites and training material referring to these terms. It would also require the re-education of those who are familiar with these terms from IPv4. This process would be expensive. In addition to this, these terms are already defined in Section II of the IPv6 Address Allocation and Assignment Policy document. Changing these terms in the Database would require a significant rewrite to the policy itself. There was also a discussion as to whether the status attribute should reflect the portability of IPv6 address space. In the RIPE NCC Service Region there is a policy allowing /32 blocks to be issued to the networks hosting Root Nameservers. There is also a policy allowing IXP networks to receive a /64 or /48 for neutral peering meshes. However, there is not (yet) a policy allowing End User networks to receive a block of Provider Independent address space. Until there is a policy allowing End Users to carry address space with them when they change providers it is probably not appropriate to give assignments a status indicating that they are *not* portable. For these reasons the RIPE NCC would like to implement the new status attribute, as described on 31 May 2002 and above, as soon as possible. The software implementation will allow configuration of different labeling for the status attribute quite easily. Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From webmaster at ripe.net Thu Jul 4 13:59:40 2002 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Thu, 04 Jul 2002 13:59:40 +0200 Subject: [lir-wg] New Document available: RIPE-244 Message-ID: <200207041159.g64BxeC15707@birch.ripe.net> 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 From hank at att.net.il Fri Jul 5 08:51:28 2002 From: hank at att.net.il (Hank Nussbacher) Date: Fri, 05 Jul 2002 09:51:28 +0300 Subject: [lir-wg] New Document available: RIPE-244 In-Reply-To: <200207041159.g64BxeC15707@birch.ripe.net> Message-ID: <5.1.0.14.2.20020705095029.01025c90@max.att.net.il> At 01:59 PM 04-07-02 +0200, RIPE NCC Document Announcement Service wrote: Shouldn't this be listed at: http://www.ripe.net/ripe/docs/titletoc.html http://www.ripe.net/ripe/docs/internet-registries.html as well? -Hank >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 From gert at space.net Mon Jul 8 14:41:33 2002 From: gert at space.net (Gert Doering) Date: Mon, 8 Jul 2002 14:41:33 +0200 Subject: [lir-wg] Discussion Summary: Status field for inet6num objects In-Reply-To: <20020701162124.GA23386@ripe.net>; from leo@ripe.net on Mon, Jul 01, 2002 at 06:21:24PM +0200 References: <20020701162124.GA23386@ripe.net> Message-ID: <20020708144133.W13357@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Guy.Davies at telindus.co.uk Mon Jul 8 14:53:02 2002 From: Guy.Davies at telindus.co.uk (Guy Davies) Date: Mon, 8 Jul 2002 13:53:02 +0100 Subject: [lir-wg] Discussion Summary: Status field for inet6num object s Message-ID: -----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 at space.net] > Sent: Monday, July 08, 2002 1:42 PM > To: leo vegoda > Cc: ipv6-wg at ripe.net; lir-wg at ripe.net; db-wg at ripe.net; > sig-db at apnic.net; > policy-db at apnic.net; apnic-talk at 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 at 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. From gert at space.net Mon Jul 8 14:58:28 2002 From: gert at space.net (Gert Doering) Date: Mon, 8 Jul 2002 14:58:28 +0200 Subject: [lir-wg] Discussion Summary: Status field for inet6num object s In-Reply-To: ; from Guy.Davies@telindus.co.uk on Mon, Jul 08, 2002 at 01:53:02PM +0100 References: Message-ID: <20020708145828.Z13357@Space.Net> Hi, On Mon, Jul 08, 2002 at 01:53:02PM +0100, Guy Davies wrote: > 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. That would be fine with me. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45809 (45931) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From leo at ripe.net Tue Jul 9 11:53:14 2002 From: leo at ripe.net (leo vegoda) Date: Tue, 9 Jul 2002 11:53:14 +0200 Subject: [lir-wg] AS Number Policy Message-ID: <20020709095314.GB16848@ripe.net> 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 From hank at att.net.il Tue Jul 9 11:57:46 2002 From: hank at att.net.il (Hank Nussbacher) Date: Tue, 09 Jul 2002 12:57:46 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: <20020709095314.GB16848@ripe.net> Message-ID: <5.1.0.14.2.20020709125553.00fcbe70@max.att.net.il> At 11:53 AM 09-07-02 +0200, leo vegoda wrote: >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'? 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. -Hank >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 From neil at COLT.NET Tue Jul 9 12:01:12 2002 From: neil at COLT.NET (Neil J. McRae) Date: Tue, 9 Jul 2002 11:01:12 +0100 Subject: [lir-wg] AS Number Policy In-Reply-To: <20020709095314.GB16848@ripe.net> Message-ID: Leo, > 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'? 3 months. Any thing else can be done on an exception basis. But you better carefully define "'on-line'"! :) > > 2. After how many months of not being in use should an AS be > returned? > Again I think 3 months, but as you assuming that this is when the AS is no longer "'on-line'" ? I think there should then be a period of non-use [6 months or so?] before that ASes that are returned get reused, and some form of communications plan around the re-allocation of an AS. Imagine what might happen when 1755 gets re-issued? :) Regards, Neil. From wtremmel at vianetworks.com Tue Jul 9 13:10:39 2002 From: wtremmel at vianetworks.com (Wolfgang Tremmel, WT5-RIPE) Date: Tue, 9 Jul 2002 13:10:39 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: <20020709095314.GB16848@ripe.net> Message-ID: Hello, > 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'? 3 months (it seems there is agreement) > > 2. After how many months of not being in use should an AS be > returned? 6 months Companies get bought, ASes get merged, companies got sold, ASes get split again We should allow a slightly longer period here. Wolfgang From woeber at cc.univie.ac.at Tue Jul 9 13:31:36 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 09 Jul 2002 13:31:36 +0200 Subject: [lir-wg] AS Number Policy Message-ID: <00A10AD5.695A6E1A.11@cc.univie.ac.at> >1. How long does the community believe it is reasonable to take to > bring an AS 'on-line'? What is the definiton of "on-line" here? Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From vovik at lucky.net Tue Jul 9 13:07:32 2002 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Jul 2002 14:07:32 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: <20020709095314.GB16848@ripe.net> References: <20020709095314.GB16848@ripe.net> Message-ID: <20020709110732.GO23389@lucky.net> On Tue, Jul 09, 2002 at 11:53:14AM +0200, leo vegoda wrote: >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. Would it be possible to define term multihomed more clearly? Does it mean that AS just should have more than one eBGP peer? Lets see the following example: +-----------+ +-------+ | AS-UPLINK | | AS-IX | +---------o-+ +o------+ | | +o-----------o+ | AS-CUSTOMER | +-------------+ AS-CUSTOMER is world-visible through AS-UPLINK and limited visible to some ASes through AS-IX. Should AS-CUSTOMER be considered as multihomed? -- Regards, Vladimir. From oppermann at tix.ch Tue Jul 9 13:40:57 2002 From: oppermann at tix.ch (Andre Oppermann) Date: Tue, 09 Jul 2002 13:40:57 +0200 Subject: [lir-wg] AS Number Policy References: <00A10AD5.695A6E1A.11@cc.univie.ac.at> Message-ID: <3D2ACBC9.DBDFF72B@tix.ch> "Wilfried Woeber, UniVie/ACOnet" wrote: > > >1. How long does the community believe it is reasonable to take to > > bring an AS 'on-line'? > > What is the definiton of "on-line" here? RIPE is running the RIS and is collecting data from many route servers at exchange points and other places. If a AS does not appear in any of these datasets it is most likely not online in the global Internet. -- Andre From vovik at lucky.net Tue Jul 9 13:42:26 2002 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Jul 2002 14:42:26 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: <00A10AD5.695A6E1A.11@cc.univie.ac.at> References: <00A10AD5.695A6E1A.11@cc.univie.ac.at> Message-ID: <20020709114226.GR23389@lucky.net> On Tue, Jul 09, 2002 at 01:31:36PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: >>1. How long does the community believe it is reasonable to take to >> bring an AS 'on-line'? > > What is the definiton of "on-line" here? I think it depends on how RIPE are going to check that. AFAIK RIPE uses RIS (http://www.ripe.net/ripencc/pub-services/np/ris/) for that. -- Regards, Vladimir. From wtremmel at vianetworks.com Tue Jul 9 14:10:34 2002 From: wtremmel at vianetworks.com (Wolfgang Tremmel, WT5-RIPE) Date: Tue, 9 Jul 2002 14:10:34 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: <20020709110732.GO23389@lucky.net> Message-ID: I'd say yes, also if it perhaps once was intended differently. There are a number of ISPs out there which have for cost reasons only one upstream provider, but want to (also for cost reasons) peer at an exchange. This might not be the most redundant approach, but we should not tell them how to run their business. What would happen if we'd not allow this? Just more wrong entries in the RIPE database..... best regards, Wolfgang > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On > Behalf Of Vladimir A. Jakovenko > Sent: Tuesday, July 09, 2002 1:08 PM > To: leo vegoda > Cc: lir-wg at ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Tue, Jul 09, 2002 at 11:53:14AM +0200, leo vegoda wrote: > >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. > > Would it be possible to define term multihomed more clearly? > Does it mean that AS just should have more than one eBGP peer? > > Lets see the following example: > > +-----------+ +-------+ > | AS-UPLINK | | AS-IX | > +---------o-+ +o------+ > | | > +o-----------o+ > | AS-CUSTOMER | > +-------------+ > > AS-CUSTOMER is world-visible through AS-UPLINK and limited visible to some > ASes through AS-IX. > > Should AS-CUSTOMER be considered as multihomed? > > -- > Regards, > Vladimir. From peter.galbavy at knowtion.net Tue Jul 9 14:41:46 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 9 Jul 2002 13:41:46 +0100 Subject: [lir-wg] AS Number Policy References: Message-ID: <016101c22745$fd5380d0$2728a8c0@carpenter> Or, like me, you only have one *transit* provider, but a number of (small) private peering connections. Yes, the use of private/fake AS space is feasible, but the same issues arise as with the misuse of RFC1918 space between organisaions. Peter ----- Original Message ----- From: "Wolfgang Tremmel, WT5-RIPE" To: "Vladimir A. Jakovenko" ; "leo vegoda" Cc: Sent: Tuesday, July 09, 2002 1:10 PM Subject: RE: [lir-wg] AS Number Policy > I'd say yes, also if it perhaps once was intended differently. > > There are a number of ISPs out there which have for cost reasons > only one upstream provider, but want to (also for cost reasons) > peer at an exchange. > This might not be the most redundant approach, but we should > not tell them how to run their business. > > What would happen if we'd not allow this? Just more wrong > entries in the RIPE database..... > > best regards, > Wolfgang > > > > -----Original Message----- > > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On > > Behalf Of Vladimir A. Jakovenko > > Sent: Tuesday, July 09, 2002 1:08 PM > > To: leo vegoda > > Cc: lir-wg at ripe.net > > Subject: Re: [lir-wg] AS Number Policy > > > > > > On Tue, Jul 09, 2002 at 11:53:14AM +0200, leo vegoda wrote: > > >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. > > > > Would it be possible to define term multihomed more clearly? > > Does it mean that AS just should have more than one eBGP peer? > > > > Lets see the following example: > > > > +-----------+ +-------+ > > | AS-UPLINK | | AS-IX | > > +---------o-+ +o------+ > > | | > > +o-----------o+ > > | AS-CUSTOMER | > > +-------------+ > > > > AS-CUSTOMER is world-visible through AS-UPLINK and limited visible to some > > ASes through AS-IX. > > > > Should AS-CUSTOMER be considered as multihomed? > > > > -- > > Regards, > > Vladimir. > > From beri at kpnqwest.net Tue Jul 9 15:33:53 2002 From: beri at kpnqwest.net (Berislav Todorovic) Date: Tue, 9 Jul 2002 15:33:53 +0200 (CEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <20020709095314.GB16848@ripe.net> Message-ID: 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 From matthew at crescent.org.uk Tue Jul 9 15:56:54 2002 From: matthew at crescent.org.uk (Matthew Robinson) Date: Tue, 09 Jul 2002 14:56:54 +0100 Subject: [lir-wg] AS Number Policy In-Reply-To: Your message of "Tue, 09 Jul 2002 14:42:26 +0300." <20020709114226.GR23389@lucky.net> Message-ID: 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 From woeber at cc.univie.ac.at Tue Jul 9 16:06:18 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 09 Jul 2002 16:06:18 +0200 Subject: [lir-wg] AS Number Policy Message-ID: <00A10AEB.063F7B2A.3@cc.univie.ac.at> 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 To: leo vegoda CC: lir-wg at 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 -------------------------------------------------------------------------------- From woeber at cc.univie.ac.at Tue Jul 9 18:11:04 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 09 Jul 2002 18:11:04 +0200 Subject: [lir-wg] AS Number Policy Message-ID: <00A10AFC.7428042A.8@cc.univie.ac.at> >Lets see the following example: > > +-----------+ +-------+ > | AS-UPLINK | | AS-IX | > +---------o-+ +o------+ > | | > +o-----------o+ > | AS-CUSTOMER | > +-------------+ > >[ ... ] > >Should AS-CUSTOMER be considered as multihomed? Definitely, as they'd probably have more then one eBPG session, and probably a different routing policy. I don't see any reason to treat "customer" status (i.e. packets shipped for money) different from "peering" status (i.e. packets shipped for "free"). >-- >Regards, >Vladimir. Wilfried. From PLu at cw.net Tue Jul 9 18:54:46 2002 From: PLu at cw.net (Lu, Ping) Date: Tue, 9 Jul 2002 12:54:46 -0400 Subject: [lir-wg] AS Number Policy Message-ID: 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 at cw.net > -----Original Message----- > From: Matthew Robinson [mailto:matthew at crescent.org.uk] > Sent: Tuesday, July 09, 2002 9:57 AM > To: Vladimir A. Jakovenko > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg at 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 > From wtremmel at vianetworks.com Tue Jul 9 19:27:29 2002 From: wtremmel at vianetworks.com (Wolfgang Tremmel, WT5-RIPE) Date: Tue, 9 Jul 2002 19:27:29 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: Message-ID: If it is nowhere advertised you could use a privat AS-number... Wolfgang > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at 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 at 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 at cw.net > > > > > -----Original Message----- > > From: Matthew Robinson [mailto:matthew at crescent.org.uk] > > Sent: Tuesday, July 09, 2002 9:57 AM > > To: Vladimir A. Jakovenko > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg at 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 > > From PLu at cw.net Tue Jul 9 20:01:26 2002 From: PLu at cw.net (Lu, Ping) Date: Tue, 9 Jul 2002 14:01:26 -0400 Subject: [lir-wg] AS Number Policy Message-ID: 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 at cw.net > -----Original Message----- > From: Wolfgang Tremmel, WT5-RIPE [mailto:wtremmel at 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 at 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 at ripe.net > [mailto:owner-lir-wg at 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 at 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 at cw.net > > > > > > > > > -----Original Message----- > > > From: Matthew Robinson [mailto:matthew at crescent.org.uk] > > > Sent: Tuesday, July 09, 2002 9:57 AM > > > To: Vladimir A. Jakovenko > > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg at 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 > > > > From PLu at cw.net Tue Jul 9 21:57:49 2002 From: PLu at cw.net (Lu, Ping) Date: Tue, 9 Jul 2002 15:57:49 -0400 Subject: [lir-wg] AS Number Policy Message-ID: Several examples: 1. Confederate AS : only the top level AS number is announced by design, all member ASes should not be visible outside the confederate. 2. CIDR aggregate : If customer's address got aggregated by upstream ISP, usually you won't see their AS numbers from the upstream ISP's CIDR (especially for those people like to filter on allocation boundary). Technically I don't see how RIPE NCC can possibly find all the ASes that are originated but invisible to the public route server. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik at lucky.net] > Sent: Tuesday, July 09, 2002 3:26 PM > To: Lu, Ping > Cc: 'wtremmel at vianetworks.com'; 'Matthew Robinson'; Wilfried > Woeber, UniVie/ACOnet; lir-wg at ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Tue, Jul 09, 2002 at 02:01:26PM -0400, Lu, Ping wrote: > >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 ? > > Could you possibly provide us with more examples in which > circumstances someone > may need to use AS number from the PUBLIC range instead of > using AS number from > PRIVATE range in the case when there is no need to advertise > any prefixes > originated by such AS-number to the PUBLIC Internet (i.e. > this AS number will > never be visible outside of some private network)? > > I can remind only one case - some kind of IX, are used by > some ASes to > exchange routing information localy. Generaly speaking IX-AS > may not be > visible from PUBLIC, but in the most cases, especialy if we > are talking > about enterprise networks, same results may be achieved by > using AS-number > from private range. > > By way of proof - AS15645 is used for the public Ukrainian > Internet-Exchange. > Appearance of any prefixes originated by this AS outside of > IX members networks > violates IX rules and should be avoided. > > Lets summarise - there ARE circumstances when AS number from > PUBLIC range may > be requested and used being invisible from the majority of > the Internet. > > It would be nice to mention that in policy and provide some examples. > > -- > Regards, > Vladimir. > From peter.galbavy at knowtion.net Tue Jul 9 22:26:03 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 9 Jul 2002 21:26:03 +0100 Subject: [lir-wg] AS Number Policy References: Message-ID: <008201c22786$d938e280$79cb87d4@walrus> And when two organisations interconnect using a private peering ? Filters are great, but similar foul ups can and will occur as with the use of RFC1918 address space, as per my previous rant^We-mail. Peter ----- Original Message ----- From: "Wolfgang Tremmel, WT5-RIPE" To: "Lu, Ping" ; "'Matthew Robinson'" ; "Vladimir A. Jakovenko" Cc: "Wilfried Woeber, UniVie/ACOnet" ; Sent: Tuesday, July 09, 2002 6:27 PM 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 at ripe.net [mailto:owner-lir-wg at 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 at 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 at cw.net > > > > > > > > > -----Original Message----- > > > From: Matthew Robinson [mailto:matthew at crescent.org.uk] > > > Sent: Tuesday, July 09, 2002 9:57 AM > > > To: Vladimir A. Jakovenko > > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg at 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 > > > > From PLu at cw.net Tue Jul 9 23:21:15 2002 From: PLu at cw.net (Lu, Ping) Date: Tue, 9 Jul 2002 17:21:15 -0400 Subject: [lir-wg] AS Number Policy Message-ID: See the inline comment. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik at lucky.net] > Sent: Tuesday, July 09, 2002 4:16 PM > To: Lu, Ping > Cc: 'wtremmel at vianetworks.com'; 'Matthew Robinson'; Wilfried > Woeber, UniVie/ACOnet; lir-wg at ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Tue, Jul 09, 2002 at 03:57:49PM -0400, Lu, Ping wrote: > >Several examples: > > > >1. Confederate AS : only the top level AS number is > announced by design, all > >member ASes should not be visible outside the confederate. > > What is the reason (or advantage) in using AS numbers from > PUBLIC pool for > confederate ASes, if they are not visible outside of confederation? > Why do you think confederate AS should belong to the same company ? And you can force one of them to use private AS ? > >2. CIDR aggregate : If customer's address got aggregated by > upstream ISP, > >usually you won't see their AS numbers from the upstream ISP's CIDR > >(especially for those people like to filter on allocation boundary). > > 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? > Huh ? RIPE NCC always recommends that the end user should use PA address from the upstream ISP so only the less specific CIDR (with ISP's AS number) will appear in the GLOBAL routing table and the more specific prefixes (with end user's AS number) WON'T POLLUTE the GLOBAL routing table.Now in order to show their assigned AS numbers, end user will have to POLLUTE the GLOBAL routing table with their more specific prefixes. > I may imagine only one case - customer's AS peering with public IX. > Yes, IX is another example that AS is originated but not visible in the GLOBAL routing table. > >Technically I don't see how RIPE NCC can possibly find all > the ASes that are > >originated but invisible to the public route server. > > Agree. But there are also administrative possibilites. > > -- > Regards, > Vladimir. > From ripe-lir-wg at chriss.net Wed Jul 10 00:08:40 2002 From: ripe-lir-wg at chriss.net (Christopher Sharp) Date: Tue, 09 Jul 2002 22:08:40 +0000 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: On Wed, 10 Jul 2002 00:17:20 +0300 (IDT), Hank Nussbacher wrote: >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? I agree. However, I think the community is agreed that an AS return policy is needed. What that policy is and how it is implemented is going to be the harder question to answer. For new applicants I believe 3 months should be enough to bring their new AS on-line. It should also be soon enough after the initial registration to guarantee having accurate contact details for the applicant (either from the registration or via the LIR through which it was submitted). Contact will be a lot harder with older registrations. The LIRs through which such applications were made often no-longer have contact with the maintainers. Contacting the maintainers of long-unused ASNs will be problematic. I imagine a large percentage of registrants will simply no-longer exist and their contacts will have moved on. I believe a general RIPE policy is needed to cover all unused registrations where the registrant no-longer exists - or have I missed something? The sooner RIPE contacts the mntner of an AS after it appears to become unused the better the chances of making contact and a successful return of the ASN. This is why I back a short period of disuse before the mntner is contacted requesting return of the ASN. I think we will see a pattern of depreciating contactability for those whose ASN is in use but no-longer multi-homed. Many of these registrants are in the process of down-sizing and have no strong technical focus. This means registered mntners are less likely to be available as time goes on and there may be no skilled replacement contact available. Early communication with such registrants will be critical in negotiating the return of their unused AS. For this reason I suggest a 6 month period before contact is made, followed by a 3 month period for "migration" from the single-homed AS. I agree with Neil [apologies if it was not you] that there should be a long period before a returned AS is released. The question of what is to be done when no mntner can be contacted for an apparently disused object is a much larger problem to address and is not specific to ASNs. >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? Whilst this is a very valid point I hope registrants like these are in the minority. The refusal of a few members to observe protocol is not a reason not to define a policy and attempt to enforce it. I suspect that many of the single-homed AS in use still have a relationship with the LIR through which the application was made, in which case pressure could be brought to bear with the LIR to assist. Ultimately the community will decide if they feel strongly enough to bring such offenders to justice. This is likely to take the form of bogon filters. C. From pekkas at netcore.fi Wed Jul 10 09:03:38 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 10 Jul 2002 10:03:38 +0300 (EEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <00A10AFC.7428042A.8@cc.univie.ac.at> Message-ID: On Tue, 9 Jul 2002, Wilfried Woeber, UniVie/ACOnet wrote: > >Lets see the following example: > > > > +-----------+ +-------+ > > | AS-UPLINK | | AS-IX | > > +---------o-+ +o------+ > > | | > > +o-----------o+ > > | AS-CUSTOMER | > > +-------------+ > > > >[ ... ] > > > >Should AS-CUSTOMER be considered as multihomed? > > Definitely, as they'd probably have more then one eBPG session, and > probably a different routing policy. > > I don't see any reason to treat "customer" status (i.e. packets shipped > for money) different from "peering" status (i.e. packets shipped for > "free"). In this case, RIPE would have to have presence at every IX to not to get false positives. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From vovik at lucky.net Tue Jul 9 21:25:30 2002 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Jul 2002 22:25:30 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <20020709192530.GY23389@lucky.net> On Tue, Jul 09, 2002 at 02:01:26PM -0400, Lu, Ping wrote: >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 ? Could you possibly provide us with more examples in which circumstances someone may need to use AS number from the PUBLIC range instead of using AS number from PRIVATE range in the case when there is no need to advertise any prefixes originated by such AS-number to the PUBLIC Internet (i.e. this AS number will never be visible outside of some private network)? I can remind only one case - some kind of IX, are used by some ASes to exchange routing information localy. Generaly speaking IX-AS may not be visible from PUBLIC, but in the most cases, especialy if we are talking about enterprise networks, same results may be achieved by using AS-number from private range. By way of proof - AS15645 is used for the public Ukrainian Internet-Exchange. Appearance of any prefixes originated by this AS outside of IX members networks violates IX rules and should be avoided. Lets summarise - there ARE circumstances when AS number from PUBLIC range may be requested and used being invisible from the majority of the Internet. It would be nice to mention that in policy and provide some examples. -- Regards, Vladimir. From vovik at lucky.net Tue Jul 9 22:02:17 2002 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Jul 2002 23:02:17 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: <00A10AFC.7428042A.8@cc.univie.ac.at> References: <00A10AFC.7428042A.8@cc.univie.ac.at> Message-ID: <20020709200217.GZ23389@lucky.net> On Tue, Jul 09, 2002 at 06:11:04PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: >>Lets see the following example: >> >> +-----------+ +-------+ >> | AS-UPLINK | | AS-IX | >> +---------o-+ +o------+ >> | | >> +o-----------o+ >> | AS-CUSTOMER | >> +-------------+ >> >>[ ... ] >> >>Should AS-CUSTOMER be considered as multihomed? > > Definitely, as they'd probably have more then one eBPG session, and > probably a different routing policy. Ok, so the word 'multihomed' can be replaced or described as "in the case of two or more eBGP sessions with public ASes", right? > I don't see any reason to treat "customer" status (i.e. packets shipped > for money) different from "peering" status (i.e. packets shipped for > "free"). In other words, if customer B would like to resell service from uplink A to two other customers (C and D) it should be allowed to get AS number for that: +------+ | AS-A | +---o--+ | +---o--+ | AS-B | +-o--o-+ | | +-----+ +-----+ | | +---o--+ +--o---+ | AS-C | | AS-D | +------+ +------+ right (lets omit details how AS-C and AS-D achieve they multihoming)? -- Regards, Vladimir. From hank at att.net.il Tue Jul 9 23:11:40 2002 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 10 Jul 2002 00:11:40 +0300 (IDT) Subject: [lir-wg] AS Number Policy In-Reply-To: Message-ID: On Tue, 9 Jul 2002, Lu, Ping wrote: > Several examples: > > 1. Confederate AS : only the top level AS number is announced by design, all > member ASes should not be visible outside the confederate. > 2. CIDR aggregate : If customer's address got aggregated by upstream ISP, > usually you won't see their AS numbers from the upstream ISP's CIDR > (especially for those people like to filter on allocation boundary). > > Technically I don't see how RIPE NCC can possibly find all the ASes that are > originated but invisible to the public route server. I think if RIPE contacts an AS and says they are not multihomed and the AS can prove they are via some unknown LG or route server to some small local IXP that RIPE doesn't monitor - I say RIPE should record it as multihomed and close the ticket. -Hank > > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu at cw.net > > > > -----Original Message----- > > From: Vladimir A. Jakovenko [mailto:vovik at lucky.net] > > Sent: Tuesday, July 09, 2002 3:26 PM > > To: Lu, Ping > > Cc: 'wtremmel at vianetworks.com'; 'Matthew Robinson'; Wilfried > > Woeber, UniVie/ACOnet; lir-wg at ripe.net > > Subject: Re: [lir-wg] AS Number Policy > > > > > > On Tue, Jul 09, 2002 at 02:01:26PM -0400, Lu, Ping wrote: > > >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 ? > > > > Could you possibly provide us with more examples in which > > circumstances someone > > may need to use AS number from the PUBLIC range instead of > > using AS number from > > PRIVATE range in the case when there is no need to advertise > > any prefixes > > originated by such AS-number to the PUBLIC Internet (i.e. > > this AS number will > > never be visible outside of some private network)? > > > > I can remind only one case - some kind of IX, are used by > > some ASes to > > exchange routing information localy. Generaly speaking IX-AS > > may not be > > visible from PUBLIC, but in the most cases, especialy if we > > are talking > > about enterprise networks, same results may be achieved by > > using AS-number > > from private range. > > > > By way of proof - AS15645 is used for the public Ukrainian > > Internet-Exchange. > > Appearance of any prefixes originated by this AS outside of > > IX members networks > > violates IX rules and should be avoided. > > > > Lets summarise - there ARE circumstances when AS number from > > PUBLIC range may > > be requested and used being invisible from the majority of > >the Internet. > > > > It would be nice to mention that in policy and provide some examples. > > > > -- > > Regards, > > Vladimir. > > > Hank Nussbacher From vovik at lucky.net Tue Jul 9 22:15:48 2002 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Tue, 9 Jul 2002 23:15:48 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <20020709201548.GA23389@lucky.net> On Tue, Jul 09, 2002 at 03:57:49PM -0400, Lu, Ping wrote: >Several examples: > >1. Confederate AS : only the top level AS number is announced by design, all >member ASes should not be visible outside the confederate. What is the reason (or advantage) in using AS numbers from PUBLIC pool for confederate ASes, if they are not visible outside of confederation? >2. CIDR aggregate : If customer's address got aggregated by upstream ISP, >usually you won't see their AS numbers from the upstream ISP's CIDR >(especially for those people like to filter on allocation boundary). 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? I may imagine only one case - customer's AS peering with public IX. >Technically I don't see how RIPE NCC can possibly find all the ASes that are >originated but invisible to the public route server. Agree. But there are also administrative possibilites. -- Regards, Vladimir. From hank at att.net.il Tue Jul 9 23:17:20 2002 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 10 Jul 2002 00:17:20 +0300 (IDT) Subject: [lir-wg] AS Number Policy In-Reply-To: Message-ID: On Tue, 9 Jul 2002, Christopher Sharp wrote: > On Tue, 09 Jul 2002 12:57:46 +0300, Hank Nussbacher 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 From hank at att.net.il Wed Jul 10 09:01:34 2002 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 10 Jul 2002 10:01:34 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <5.1.0.14.2.20020710094655.054bad00@max.att.net.il> At 10:08 PM 09-07-02 +0000, Christopher Sharp wrote: >Contacting the maintainers of long-unused ASNs will be problematic. I >imagine a >large percentage of registrants will simply no-longer exist and their contacts >will have moved on. I believe a general RIPE policy is needed to cover all >unused registrations where the registrant no-longer exists - or have I missed >something? The LIR that allocated the ASN should be able to handle its removal. I have started creating mntner objects for new ASNs with duplicate auth tags ( with different MD5-PW passwords). I give one to the requesting organization and one I keep for myself. In the event the company goes bankrupt and I can't find anyone to talk to in the company, then I at least have the ability to remove their entry without them being around. > >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? > >Whilst this is a very valid point I hope registrants like these are in the >minority. The refusal of a few members to observe protocol is not a >reason not >to define a policy and attempt to enforce it. I suspect that many of the >single-homed AS in use still have a relationship with the LIR through >which the >application was made, in which case pressure could be brought to bear with the >LIR to assist. > >Ultimately the community will decide if they feel strongly enough to bring >such >offenders to justice. This is likely to take the form of bogon filters. I don't think we have to resort to the courts for this and I doubt they would help. But the problem is not only with ASNs but also with IP blocks being advertised by organizations that don't own them. Those that get routing-wg at ripe.net see the list every week of unallocated ASNs and IP blocks being used freely on the Internet. I'd like to make a suggestion. Since these ASNs and IP blocks are the property of the RIRs, and since organizations are cybersquatting on these resources why shouldn't these RIRs advertise these IP blocks and ASNs themselves and blackhole them to their routers? You'd get the attention of these cybersquatting organizations *real* fast. -Hank >C. From andrei at ripe.net Wed Jul 10 11:21:38 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 10 Jul 2002 11:21:38 +0200 Subject: [lir-wg] AS Number Policy References: Message-ID: <3D2BFCA2.1030804@ripe.net> Dear Hank, Hank Nussbacher wrote: [...] > > 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? > Yes, the RIPE NCC have such general policy indeed. But there are exceptions especially when it comes to conflicts with the RS data. If someone has a record in the Database that they have not been delegated this record will be deleted if necessary. Many of such records are from the old times when the database was much less secure. Regards, Andrei Robachevsky DB Group RIPE NCC From ripe-lir-wg at chriss.net Wed Jul 10 12:05:12 2002 From: ripe-lir-wg at chriss.net (Christopher Sharp) Date: Wed, 10 Jul 2002 10:05:12 +0000 Subject: [lir-wg] AS Number Policy In-Reply-To: <5.1.0.14.2.20020710094655.054bad00@max.att.net.il> References: <5.1.0.14.2.20020710094655.054bad00@max.att.net.il> Message-ID: On Wed, 10 Jul 2002 10:01:34 +0300, Hank Nussbacher wrote: >At 10:08 PM 09-07-02 +0000, Christopher Sharp wrote: > >The LIR that allocated the ASN should be able to handle its removal. I >have started creating mntner objects for new ASNs with duplicate auth tags >( with different MD5-PW passwords). I give one to the requesting >organization and one I keep for myself. In the event the company goes >bankrupt and I can't find anyone to talk to in the company, then I at least >have the ability to remove their entry without them being around. This is excellent for future registrations but doesn't help with historical allocations that were not done like this. Especially where the allocating LIR has had no contact with the registrant for an extended period of time. I suspect we need to look back, as well as forward, when implementing a solution. >I don't think we have to resort to the courts for this and I doubt they >would help. But the problem is not only with ASNs but also with IP blocks >being advertised by organizations that don't own them. Those that get >routing-wg at ripe.net see the list every week of unallocated ASNs and IP >blocks being used freely on the Internet. I'd like to make a >suggestion. Since these ASNs and IP blocks are the property of the RIRs, >and since organizations are cybersquatting on these resources why shouldn't >these RIRs advertise these IP blocks and ASNs themselves and blackhole them >to their routers? > >You'd get the attention of these cybersquatting organizations *real* fast. To succeed in grabbing the attention of all such offenders you probably need the support of all RIRs and IANA to carry out a unilateral crackdown. Otherwise the skilled offenders will just migrate to other unallocated address space. An informal approach such as the wider distribution of this list may well help. I'm sure a lot of people would start listing many of these ASNs and IP blocks in their filters. C. From woeber at cc.univie.ac.at Wed Jul 10 12:24:12 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 10 Jul 2002 12:24:12 +0200 Subject: [lir-wg] AS Number Policy Message-ID: <00A10B95.29C4575A.15@cc.univie.ac.at> >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 From beri at kpnqwest.net Wed Jul 10 12:38:03 2002 From: beri at kpnqwest.net (Berislav Todorovic) Date: Wed, 10 Jul 2002 12:38:03 +0200 (CEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <5.1.0.14.2.20020710094655.054bad00@max.att.net.il> Message-ID: On Wed, 10 Jul 2002, Hank Nussbacher wrote: >> I'd like to make a suggestion. Since these ASNs and IP blocks are the >> property of the RIRs, and since organizations are cybersquatting on >> these resources why shouldn't these RIRs advertise these IP blocks and >> ASNs themselves and blackhole them to their routers? I'd like to back this idea! However, even if ICANN itself suddenly gets stroken by lightning of technical wisdom and starts announcing unused /8's - that won't prevent offenders from announcing more specific routes, will it? On the other hand, announcing /24's will really pollute the global routing table, which is big enough anyway. Still, having a service like Paul Vixie's AS7777 would help a lot: an ISP willing to receive blackhole routes would bring a route server on their backbone, establish a peering session with "IANA blackhole AS" and use the routes to construct filters etc. Regards, Beri From dr at cluenet.de Wed Jul 10 12:42:56 2002 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 10 Jul 2002 12:42:56 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: <20020709114226.GR23389@lucky.net>; from vovik@lucky.net on Tue, Jul 09, 2002 at 02:42:26PM +0300 References: <00A10AD5.695A6E1A.11@cc.univie.ac.at> <20020709114226.GR23389@lucky.net> Message-ID: <20020710124256.A19545@homebase.cluenet.de> On Tue, Jul 09, 2002 at 02:42:26PM +0300, Vladimir A. Jakovenko wrote: > On Tue, Jul 09, 2002 at 01:31:36PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > >>1. How long does the community believe it is reasonable to take to > >> bring an AS 'on-line'? > > > > What is the definiton of "on-line" here? > > I think it depends on how RIPE are going to check that. Yes. I had recently a lengthy "discussion" with RIPE hostmasters about a multihomed AS of a customer. Primary upstream with us, secondary upstream with AS702. Using 702:80 community to lower localpref within 702, making the backup link real backup. As 702 announces best path (which is via their peering to us to the customer), RIPE was unable to see the 702 backup announcement anywhere. Explanation of BGP basics by myself were not understood or ignored. Or both. They also did not contact AS702 for simple confirmation of what I've told them. Took three or four emails to get that finally sorted out. Whom do I bill those 30-45 minutes to (rhetoric question)? ;-> End of the story was that they finally said "We have found AS21197 in the import policy of AS702 and going to close this ticket now." :-]]] IF they really want to enforce ASN assignment policy, they should REALLY have to have a clue about BGP. Looking at some random looking glasses or RIS data and not understanding it is NOT enough for a policy-enforcing agency. And someone should explain them the difference between a looking glass and a traceroute server. Let's say... Halabi as compulsary lecture for hostmasters who have to evaluate ASN assignment policy compliance. :-) Regards, Daniel From aid at vianw.net Wed Jul 10 12:12:29 2002 From: aid at vianw.net (Adrian Bool) Date: Wed, 10 Jul 2002 11:12:29 +0100 (BST) Subject: [lir-wg] AS Number Policy In-Reply-To: Message-ID: On Wed, 10 Jul 2002, Christopher Sharp wrote: > An informal approach such as the wider distribution of this list may well help. > I'm sure a lot of people would start listing many of these ASNs and IP blocks in > their filters. I wouldn't like to then be allocated an AS that had been on one these lists... I'd imagine that it is just for RIPE/ARIN to put pressure on the upstreams of such rogue AS holders. They could withhold the allocation of extra IP space, if necessary, to the Tranist providers in order to encourage them not to provide service to such ASs. Regards, aid -- Adrian Bool | http://noc.vianw.net/ Director, Global Core Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From aid at vianw.net Wed Jul 10 12:28:47 2002 From: aid at vianw.net (Adrian Bool) Date: Wed, 10 Jul 2002 11:28:47 +0100 (BST) Subject: [lir-wg] AS Number Policy In-Reply-To: <00A10B95.29C4575A.15@cc.univie.ac.at> Message-ID: On Wed, 10 Jul 2002, Wilfried Woeber, UniVie/ACOnet wrote: > >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 ?! ;-) Not before your next pay packet ;-) aid -- Adrian Bool | http://noc.vianw.net/ Director, Global Core Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/ From hank at att.net.il Wed Jul 10 13:29:19 2002 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 10 Jul 2002 14:29:19 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: References: <5.1.0.14.2.20020710094655.054bad00@max.att.net.il> Message-ID: <5.1.0.14.2.20020710142737.00ff4580@max.att.net.il> At 12:38 PM 10-07-02 +0200, Berislav Todorovic wrote: >On Wed, 10 Jul 2002, Hank Nussbacher wrote: > > >> I'd like to make a suggestion. Since these ASNs and IP blocks are the > >> property of the RIRs, and since organizations are cybersquatting on > >> these resources why shouldn't these RIRs advertise these IP blocks and > >> ASNs themselves and blackhole them to their routers? > >I'd like to back this idea! > >However, even if ICANN itself suddenly gets stroken by lightning of technical >wisdom and starts announcing unused /8's - that won't prevent offenders from >announcing more specific routes, will it? On the other hand, announcing /24's >will really pollute the global routing table, which is big enough anyway. Just announce those exact prefixes being announced by offenders. The prefix already appears in the routing tables so it won't increase the size of the table - just a slight memory increase for the extra paths. I don't think there are more than 100 such prefixes these days. -Hank >Still, having a service like Paul Vixie's AS7777 would help a lot: an ISP >willing to receive blackhole routes would bring a route server on their >backbone, establish a peering session with "IANA blackhole AS" and use the >routes to construct filters etc. > >Regards, >Beri From beri at kpnqwest.net Wed Jul 10 13:36:39 2002 From: beri at kpnqwest.net (Berislav Todorovic) Date: Wed, 10 Jul 2002 13:36:39 +0200 (CEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <20020710124256.A19545@homebase.cluenet.de> Message-ID: On Wed, 10 Jul 2002, Daniel Roesen wrote: >> End of the story was that they finally said "We have found AS21197 in >> the import policy of AS702 and going to close this ticket now." :-]]] Complete waste of time and energy. No wonder why the hostmaster queue is so long these days ... ;-> >> Let's say... Halabi as compulsary lecture for hostmasters who have to >> evaluate ASN assignment policy compliance. :-) Nope ... the policy evaulation must be kept as simple as possible: statement from both the customer itself, as well as at least 2 peers stated in the aut-num that there is a valid peering relationship in place must be enough to verify the policy. The customer must be asked first to update the aut-num. That same process is used when a new AS is assigned, so why invent something else for AS number usage evaluation? Of course, the problem of contacting the right party still exists. Regards, Beri From PLu at cw.net Wed Jul 10 16:38:58 2002 From: PLu at cw.net (Lu, Ping) Date: Wed, 10 Jul 2002 10:38:58 -0400 Subject: [lir-wg] AS Number Policy Message-ID: [snip] > > Yes. I had recently a lengthy "discussion" with RIPE hostmasters about > a multihomed AS of a customer. Primary upstream with us, secondary > upstream with AS702. Using 702:80 community to lower localpref within > 702, making the backup link real backup. As 702 announces best path > (which is via their peering to us to the customer), RIPE was unable to > see the 702 backup announcement anywhere. Explanation of BGP basics by > myself were not understood or ignored. Or both. They also did not > contact AS702 for simple confirmation of what I've told them. > Took three > or four emails to get that finally sorted out. Whom do I bill > those 30-45 > minutes to (rhetoric question)? ;-> > This is another good example why AS number is originated but invisible to the global routing table. > End of the story was that they finally said "We have found AS21197 in > the import policy of AS702 and going to close this ticket now." :-]]] > > IF they really want to enforce ASN assignment policy, they > should REALLY > have to have a clue about BGP. Looking at some random looking glasses > or RIS data and not understanding it is NOT enough for a > policy-enforcing agency. And someone should explain them the > difference > between a looking glass and a traceroute server. > > Let's say... Halabi as compulsary lecture for hostmasters who have to > evaluate ASN assignment policy compliance. :-) > > > Regards, > Daniel > It is almost impossible for RIPE NCC to look into all upstream ISP's routing table and verify that an AS is being used properly. If RIPE NCC can't find a way to reduce the false alarm of AS verification, the enforcement will become more likely an harassment. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From dr at cluenet.de Wed Jul 10 16:44:36 2002 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 10 Jul 2002 16:44:36 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: ; from beri@kpnqwest.net on Wed, Jul 10, 2002 at 01:36:39PM +0200 References: <20020710124256.A19545@homebase.cluenet.de> Message-ID: <20020710164436.A25012@homebase.cluenet.de> On Wed, Jul 10, 2002 at 01:36:39PM +0200, Berislav Todorovic wrote: > >> End of the story was that they finally said "We have found AS21197 in > >> the import policy of AS702 and going to close this ticket now." :-]]] > > Complete waste of time and energy. No wonder why the hostmaster queue is > so long these days ... ;-> Exactly THAT was what I was thinking of, too. > Of course, the problem of contacting the right party still exists. Yep. It's often hard to write to the correct email addr if you want to contact ASN XYZ about routing things. Often, aut-nums have only "ripe-notify at ..." etc. as addresses, tech-c being persons instead of role emails etc. (mailing persons instead of role email addresses is usually not the best thing to do).... Regards, Daniel From dr at cluenet.de Wed Jul 10 16:47:05 2002 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 10 Jul 2002 16:47:05 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: ; from PLu@cw.net on Wed, Jul 10, 2002 at 10:38:58AM -0400 References: Message-ID: <20020710164705.B25012@homebase.cluenet.de> On Wed, Jul 10, 2002 at 10:38:58AM -0400, Lu, Ping wrote: > It is almost impossible for RIPE NCC to look into all upstream ISP's routing > table and verify that an AS is being used properly. ACK. And in this specific example, the looking glass would perhaps even have to have a direct info feed from the specific aggregation router to see the path. > If RIPE NCC can't find a way to reduce the false alarm of AS verification, > the enforcement will become more likely an harassment. StrongACK. Especially, when the first email already contains a bold statement like "this AS is not multihomed, so...". Best regards, Daniel From PLu at cw.net Wed Jul 10 17:22:29 2002 From: PLu at cw.net (Lu, Ping) Date: Wed, 10 Jul 2002 11:22:29 -0400 Subject: [lir-wg] AS Number Policy Message-ID: > -----Original Message----- > From: Berislav Todorovic [mailto:beri at kpnqwest.net] > Sent: Wednesday, July 10, 2002 6:38 AM > To: Hank Nussbacher > Cc: Christopher Sharp; lir-wg at ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Wed, 10 Jul 2002, Hank Nussbacher wrote: > > >> I'd like to make a suggestion. Since these ASNs and IP > blocks are the > >> property of the RIRs, and since organizations are cybersquatting on > >> these resources why shouldn't these RIRs advertise these > IP blocks and > >> ASNs themselves and blackhole them to their routers? > > I'd like to back this idea! > > However, even if ICANN itself suddenly gets stroken by > lightning of technical > wisdom and starts announcing unused /8's - that won't prevent > offenders from > announcing more specific routes, will it? On the other hand, > announcing /24's > will really pollute the global routing table, which is big > enough anyway. I don't think to blackholing traffic is a good idea, especially when bandwidth means money in today's internet. RIRs should publish a list to include all the offending prefixes and the major ISPs will be more than happy to apply the prefix filter to block transit to those prefixes. There is already an IANA bogon filter floating around. RIPE NCC could add a filter-set object, let's say FLTR-RIPE-RESERVED-IPV4 and ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. Then all major ISPs could apply these filter to block transit traffic for these prefixes. > > Still, having a service like Paul Vixie's AS7777 would help a > lot: an ISP > willing to receive blackhole routes would bring a route > server on their > backbone, establish a peering session with "IANA blackhole > AS" and use the > routes to construct filters etc. > > Regards, > Beri > Blocking is a better idea than blackholing.... Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From PLu at cw.net Wed Jul 10 17:57:29 2002 From: PLu at cw.net (Lu, Ping) Date: Wed, 10 Jul 2002 11:57:29 -0400 Subject: [lir-wg] AS Number Policy Message-ID: > -----Original Message----- > From: Christopher Sharp [mailto:ripe-lir-wg at chriss.net] > Sent: Wednesday, July 10, 2002 11:32 AM > To: lir-wg at ripe.net > Cc: Lu, Ping > Subject: Re: [lir-wg] AS Number Policy > > > On Wed, 10 Jul 2002 11:22:29 -0400, "Lu, Ping" wrote: > > >I don't think to blackholing traffic is a good idea, especially > >when bandwidth means money in today's internet. > > I agree. Neither do I think the community should be paying > to provide the > bandwidth for such a service. > > Encouraging people to filter out these netblocks/ASNs does > make it very hard to > re-allocate them in the short term. However, most people who > maintain good > bogon filters also update them frequently, so hopefully would > remove any such > filters in plenty of time for ASNs to be re-allocated after > 12/24/36 months. > The major ISPs usually update these filters daily and if the tier-1 ISPs all have these filters then smaller ISPs don't have to filter them again. > >RIRs should publish a list to include all the offending prefixes and > >the major ISPs will be more than happy to apply the prefix filter to > >block transit to those prefixes. There is already an IANA > bogon filter > >floating around. > > This was my suggestion in a nutshell. I believe the most > commonly observed > bogon list is maintained by Rob Thomas > (http://www.cymru.com/Documents/bogon-list.html). > draft-iana-special-ipv4-03 is > IANA's most comprehensive list of special use netblocks > (http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt). > Maybe we can have an official filter-set object so people don't have to update these info manually. > >RIPE NCC could add a filter-set object, let's say > FLTR-RIPE-RESERVED-IPV4 > >and > >ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, > >APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. > >Then all major ISPs could apply these filter to block > transit traffic for > >these > >prefixes. > > This sounds excellent but doesn't cover prefixes IANA have > not yet allocated to > an RIR. This is why I would encourage frequent sharing of > this data with the > networking community and especially the maintainers of public > bogon lists on > which many people filter. > In the IANA assigned RIR range, we still need RIRs to tell us what range under their authority are not allocated yet thus should be filtered. > >Blocking is a better idea than blackholing.... > > C. > Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From ripe-lir-wg at chriss.net Wed Jul 10 17:32:02 2002 From: ripe-lir-wg at chriss.net (Christopher Sharp) Date: Wed, 10 Jul 2002 15:32:02 +0000 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: On Wed, 10 Jul 2002 11:22:29 -0400, "Lu, Ping" wrote: >I don't think to blackholing traffic is a good idea, especially >when bandwidth means money in today's internet. I agree. Neither do I think the community should be paying to provide the bandwidth for such a service. Encouraging people to filter out these netblocks/ASNs does make it very hard to re-allocate them in the short term. However, most people who maintain good bogon filters also update them frequently, so hopefully would remove any such filters in plenty of time for ASNs to be re-allocated after 12/24/36 months. >RIRs should publish a list to include all the offending prefixes and >the major ISPs will be more than happy to apply the prefix filter to >block transit to those prefixes. There is already an IANA bogon filter >floating around. This was my suggestion in a nutshell. I believe the most commonly observed bogon list is maintained by Rob Thomas (http://www.cymru.com/Documents/bogon-list.html). draft-iana-special-ipv4-03 is IANA's most comprehensive list of special use netblocks (http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt). >RIPE NCC could add a filter-set object, let's say FLTR-RIPE-RESERVED-IPV4 >and >ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, >APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. >Then all major ISPs could apply these filter to block transit traffic for >these >prefixes. This sounds excellent but doesn't cover prefixes IANA have not yet allocated to an RIR. This is why I would encourage frequent sharing of this data with the networking community and especially the maintainers of public bogon lists on which many people filter. >Blocking is a better idea than blackholing.... C. From ripe-lir-wg at chriss.net Wed Jul 10 18:24:36 2002 From: ripe-lir-wg at chriss.net (Christopher Sharp) Date: Wed, 10 Jul 2002 16:24:36 +0000 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: On Wed, 10 Jul 2002 11:57:29 -0400, "Lu, Ping" wrote: >> -----Original Message----- >> From: Christopher Sharp [mailto:ripe-lir-wg at chriss.net] >> Sent: Wednesday, July 10, 2002 11:32 AM >> To: lir-wg at ripe.net >> Cc: Lu, Ping >> Subject: Re: [lir-wg] AS Number Policy >> This was my suggestion in a nutshell. I believe the most >> commonly observed >> bogon list is maintained by Rob Thomas >> (http://www.cymru.com/Documents/bogon-list.html). [SNIP] >Maybe we can have an official filter-set object so people don't have to >update >these info manually. This sounds like an excellent idea. >In the IANA assigned RIR range, we still need RIRs to tell us >what range under their authority are not allocated yet thus should >be filtered. Yes, this information should be well publicised though so that people can build bogon filters around it. RIPE (and sometimes ARIN) announce to NANOG when they start allocating from a new /8, I've yet to see APNIC do so. I've also yet to see any of the RIRs producing a definitive list of space assigned to them which is not yet allocated. Maybe I'm not looking in the right place? C. From vovik at lucky.net Wed Jul 10 17:23:30 2002 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Wed, 10 Jul 2002 18:23:30 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: References: <00A10AFC.7428042A.8@cc.univie.ac.at> Message-ID: <20020710152330.GT23389@lucky.net> On Wed, Jul 10, 2002 at 10:03:38AM +0300, Pekka Savola wrote: >On Tue, 9 Jul 2002, Wilfried Woeber, UniVie/ACOnet wrote: >> >Lets see the following example: >> > >> > +-----------+ +-------+ >> > | AS-UPLINK | | AS-IX | >> > +---------o-+ +o------+ >> > | | >> > +o-----------o+ >> > | AS-CUSTOMER | >> > +-------------+ >> > >> >[ ... ] >> > >> >Should AS-CUSTOMER be considered as multihomed? >> >> Definitely, as they'd probably have more then one eBPG session, and >> probably a different routing policy. >> >> I don't see any reason to treat "customer" status (i.e. packets shipped >> for money) different from "peering" status (i.e. packets shipped for >> "free"). > >In this case, RIPE would have to have presence at every IX to not to get >false positives. Or in other words RIPE should modify existing policy in such way, that you may request an AS-number for IX only if you will put RIS box in this IX, right? Moreover, all existing IX-es not covered by RIS should also use RIS boxes, right? :-) -- Regards, Vladimir. From hank at att.net.il Wed Jul 10 18:58:10 2002 From: hank at att.net.il (Hank Nussbacher) Date: Wed, 10 Jul 2002 19:58:10 +0300 Subject: [lir-wg] AS Number Policy In-Reply-To: Message-ID: <5.1.0.14.2.20020710195603.00fbcd60@max.att.net.il> At 11:22 AM 10-07-02 -0400, Lu, Ping wrote: > > -----Original Message----- > > From: Berislav Todorovic [mailto:beri at kpnqwest.net] > > Sent: Wednesday, July 10, 2002 6:38 AM > > To: Hank Nussbacher > > Cc: Christopher Sharp; lir-wg at ripe.net > > Subject: Re: [lir-wg] AS Number Policy > > > > > > On Wed, 10 Jul 2002, Hank Nussbacher wrote: > > > > >> I'd like to make a suggestion. Since these ASNs and IP > > blocks are the > > >> property of the RIRs, and since organizations are cybersquatting on > > >> these resources why shouldn't these RIRs advertise these > > IP blocks and > > >> ASNs themselves and blackhole them to their routers? > > > > I'd like to back this idea! > > > > However, even if ICANN itself suddenly gets stroken by > > lightning of technical > > wisdom and starts announcing unused /8's - that won't prevent > > offenders from > > announcing more specific routes, will it? On the other hand, > > announcing /24's > > will really pollute the global routing table, which is big > > enough anyway. > >I don't think to blackholing traffic is a good idea, especially >when bandwidth means money in today's internet. > >RIRs should publish a list to include all the offending prefixes and >the major ISPs will be more than happy to apply the prefix filter to >block transit to those prefixes. There is already an IANA bogon filter >floating around. As mentioned earlier by someone, I'd hate to get an ASN or IP block that happened to be in the past inside such a published list. You can bet that somewhere, someplace, sometime, such a filter list will not be updated and will end up blocking someone inadvertantly. -Hank >RIPE NCC could add a filter-set object, let's say FLTR-RIPE-RESERVED-IPV4 >and >ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, >APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. >Then all major ISPs could apply these filter to block transit traffic for >these >prefixes. > > > > > > Still, having a service like Paul Vixie's AS7777 would help a > > lot: an ISP > > willing to receive blackhole routes would bring a route > > server on their > > backbone, establish a peering session with "IANA blackhole > > AS" and use the > > routes to construct filters etc. > > > > Regards, > > Beri > > > >Blocking is a better idea than blackholing.... > >Ping Lu >Cable & Wireless USA >Network Tools and Analysis Group >W: +1-703-292-2359 >E: plu at cw.net From john at apnic.net Thu Jul 11 04:34:14 2002 From: john at apnic.net (John Tran) Date: Thu, 11 Jul 2002 12:34:14 +1000 (EST) Subject: [hostmaster-staff] Re: [lir-wg] AS Number Policy In-Reply-To: Message-ID: On Wed, 10 Jul 2002, Christopher Sharp wrote: > On Wed, 10 Jul 2002 11:57:29 -0400, "Lu, Ping" wrote: > > >> -----Original Message----- > >> From: Christopher Sharp [mailto:ripe-lir-wg at chriss.net] > >> Sent: Wednesday, July 10, 2002 11:32 AM > >> To: lir-wg at ripe.net > >> Cc: Lu, Ping > >> Subject: Re: [lir-wg] AS Number Policy > > >> This was my suggestion in a nutshell. I believe the most > >> commonly observed > >> bogon list is maintained by Rob Thomas > >> (http://www.cymru.com/Documents/bogon-list.html). > [SNIP] > >Maybe we can have an official filter-set object so people don't have to > >update > >these info manually. > > This sounds like an excellent idea. > > >In the IANA assigned RIR range, we still need RIRs to tell us > >what range under their authority are not allocated yet thus should > >be filtered. > > Yes, this information should be well publicised though so that people can build > bogon filters around it. RIPE (and sometimes ARIN) announce to NANOG when they > start allocating from a new /8, I've yet to see APNIC do so. I've also yet to > see any of the RIRs producing a definitive list of space assigned to them which > is not yet allocated. Maybe I'm not looking in the right place? Thank you for pointing this out for us. We will certainly announce the new block in the future. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html We don't have the information about unallocated address as it is hard to maintain upto date but we do provide statistic monthly on what we have allocated. Please see: http://ftp.apnic.net/stats/apnic/ Regards Son From kurtis at kurtis.pp.se Thu Jul 11 09:57:18 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 09:57:18 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <163540000.1026374238@laptop.kurtis.pp.se> --On Tuesday, July 09, 2002 12:54:46 -0400 "Lu, Ping" wrote: > 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. Isn't that the definition of private AS? - kurtis - From pekkas at netcore.fi Thu Jul 11 10:09:49 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 11 Jul 2002 11:09:49 +0300 (EEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <163540000.1026374238@laptop.kurtis.pp.se> Message-ID: On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote: > --On Tuesday, July 09, 2002 12:54:46 -0400 "Lu, Ping" wrote: > > > 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. > > Isn't that the definition of private AS? The argument here is probably that it may be rather difficult to choose such a private AS number, if you have lots and lots of customers, that it would never clash with their customers' (depending on how it's being used) internal usage. In general, I don't think this kind of AS number use is appropriate in a bigger scale. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From wtremmel at vianetworks.com Thu Jul 11 10:15:57 2002 From: wtremmel at vianetworks.com (Wolfgang Tremmel, WT5-RIPE) Date: Thu, 11 Jul 2002 10:15:57 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: Message-ID: If the customers have customers with an AS, they may have an (official) AS too. If not, its up to you to setup a numbering plan for private AS numbers in your confederation. It seems to me, we are repeating the discussion about private IP space here... best regards, Wolfgang > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > Pekka Savola > Sent: Thursday, July 11, 2002 10:10 AM > To: Kurt Erik Lindqvist > Cc: Lu, Ping; lir-wg at ripe.net > Subject: RE: [lir-wg] AS Number Policy > > The argument here is probably that it may be rather difficult to choose > such a private AS number, if you have lots and lots of customers, that it > would never clash with their customers' (depending on how it's being used) > internal usage. > > In general, I don't think this kind of AS number use is appropriate in a > bigger scale. > From kurtis at kurtis.pp.se Thu Jul 11 10:39:29 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 10:39:29 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <277600000.1026376769@laptop.kurtis.pp.se> --On Tuesday, July 09, 2002 15:57:49 -0400 "Lu, Ping" wrote: > Several examples: > > 1. Confederate AS : only the top level AS number is announced by design, > all member ASes should not be visible outside the confederate. Which by desing should be done with private as:es. It's more or less in the instruction book. > 2. CIDR aggregate : If customer's address got aggregated by upstream ISP, > usually you won't see their AS numbers from the upstream ISP's CIDR > (especially for those people like to filter on allocation boundary). I am lost. If customer routes are aggregated by upstream, I assume the customer don't have an AS? If the customer have an AS and is multihomed you might aggregate his addresses, but you will still see the originating AS in the AS-path (or through the other path - as the customer won't get an AS unless he is multihomed). > Technically I don't see how RIPE NCC can possibly find all the ASes that > are originated but invisible to the public route server. I can't see how people should/could/would need AS:es from the public space that is not visible in the public space. - kurtis - From kurtis at kurtis.pp.se Thu Jul 11 10:45:33 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 10:45:33 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <300240000.1026377133@laptop.kurtis.pp.se> > Why do you think confederate AS should belong to the same company ? > And you can force one of them to use private AS ? Uhm...why would you like to do confederations over multiple administrative domains? Beats me. >> I may imagine only one case - customer's AS peering with public IX. >> > > Yes, IX is another example that AS is originated but not visible in the > GLOBAL routing table. If the IX doesn't provide services they wan't visible to the entire world, why can't they use a private AS? Most IX:Es will require you to announce their AS if they peer with you, so that common services (like root name-servers, NTP servers, etc) are visible to all. Then they need a public AS and it will be visible. - kurtis - From beri at kpnqwest.net Thu Jul 11 10:23:53 2002 From: beri at kpnqwest.net (Berislav Todorovic) Date: Thu, 11 Jul 2002 10:23:53 +0200 (CEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <163540000.1026374238@laptop.kurtis.pp.se> Message-ID: On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote: >> > 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. >> >> Isn't that the definition of private AS? Not exactly. There are some cases where there is a valid reason for a public AS number to be issued, despite of the fact that it has semi-private nature. Same thing applies with IP addresses - take, for example, 147.204.0.0/16 ... Regards, Beri From fredrik at sunet.se Thu Jul 11 10:47:50 2002 From: fredrik at sunet.se (Fredrik Widell) Date: Thu, 11 Jul 2002 10:47:50 +0200 (CEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <277600000.1026376769@laptop.kurtis.pp.se> Message-ID: On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote: > > > --On Tuesday, July 09, 2002 15:57:49 -0400 "Lu, Ping" wrote: > > > Several examples: > > > > 1. Confederate AS : only the top level AS number is announced by design, > > all member ASes should not be visible outside the confederate. > > Which by desing should be done with private as:es. It's more or less in the > instruction book. > > > 2. CIDR aggregate : If customer's address got aggregated by upstream ISP, > > usually you won't see their AS numbers from the upstream ISP's CIDR > > (especially for those people like to filter on allocation boundary). > > I am lost. If customer routes are aggregated by upstream, I assume the > customer don't have an AS? If the customer have an AS and is multihomed you > might aggregate his addresses, but you will still see the originating AS in > the AS-path (or through the other path - as the customer won't get an AS > unless he is multihomed). A customer can have a peer with the default transit, which aggregates the adresspace from the customer, and the customer can have other peerings via some ix:es, and the customer could perform transit to/from the ix:es to the default transit, in this scenario the customer MUST have a public AS, which you will not see in the public space, since removing private AS in the AS-path will result in somewhat unpredictable behaviour if there are several private AS involved at the customer premises. > > > > Technically I don't see how RIPE NCC can possibly find all the ASes that > > are originated but invisible to the public route server. > > I can't see how people should/could/would need AS:es from the public space > that is not visible in the public space. > > - kurtis - > -- Mvh /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 ------------------------------------------------------- From kurtis at kurtis.pp.se Thu Jul 11 11:22:45 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 11:22:45 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <631100000.1026379365@laptop.kurtis.pp.se> --On Wednesday, July 10, 2002 10:38:58 -0400 "Lu, Ping" wrote: >> Yes. I had recently a lengthy "discussion" with RIPE hostmasters about >> a multihomed AS of a customer. Primary upstream with us, secondary >> upstream with AS702. Using 702:80 community to lower localpref within >> 702, making the backup link real backup. As 702 announces best path >> (which is via their peering to us to the customer), RIPE was unable to >> see the 702 backup announcement anywhere. Explanation of BGP basics by >> myself were not understood or ignored. Or both. They also did not >> contact AS702 for simple confirmation of what I've told them. >> Took three >> or four emails to get that finally sorted out. Whom do I bill >> those 30-45 >> minutes to (rhetoric question)? ;-> >> > > This is another good example why AS number is originated but invisible > to the global routing table. > I don't read it as beeing invisible - just seen throug one path. - kurtis - From kurtis at kurtis.pp.se Thu Jul 11 11:31:57 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 11:31:57 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <686000000.1026379917@laptop.kurtis.pp.se> --On Wednesday, July 10, 2002 15:32:02 +0000 Christopher Sharp wrote: >> Then all major ISPs could apply these filter to block transit traffic for >> these >> prefixes. > > This sounds excellent but doesn't cover prefixes IANA have not yet > allocated to an RIR. This is why I would encourage frequent sharing of > this data with the networking community and especially the maintainers of > public bogon lists on which many people filter. On a side note - can we also get those major ISPs to filter packets received from their customers based on the from address? Best regards, - kurtis - From kurtis at kurtis.pp.se Thu Jul 11 11:54:54 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 11:54:54 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <29420000.1026381294@laptop.kurtis.pp.se> > The argument here is probably that it may be rather difficult to choose > such a private AS number, if you have lots and lots of customers, that it > would never clash with their customers' (depending on how it's being used) > internal usage. Uhm, you are saying that there would be singlehomed customers (let's call them A) of a ISP, that would need BGP to talk to the provider. Customer A then in turn would have single-homed customers that would need to talk BGP to them? This sounds like a very teoretical excersie to me, but maybe people are building their networks liek this. In that case I suggest they figure out how to deal with this...:) > In general, I don't think this kind of AS number use is appropriate in a > bigger scale. Correct. And the Internet is becoming pretty large scale. - kurtis - From kurtis at kurtis.pp.se Thu Jul 11 12:39:19 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 12:39:19 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <74290000.1026383959@laptop.kurtis.pp.se> >>> > 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. >>> >>> Isn't that the definition of private AS? > > Not exactly. > > There are some cases where there is a valid reason for a public AS number > to be issued, despite of the fact that it has semi-private nature. Same > thing applies with IP addresses - take, for example, 147.204.0.0/16 ... "Some cases" and "semi-private" doesn't sound to convincing to me :) I think that this is up to the definition of "publicly visible". If I have one upstream and several peers, that is to me "public". I see few (no?) other real reasons for assigning an AS that is not seen through two or more paths in the global routing table. Best regards, - kurtis - From kurtis at kurtis.pp.se Thu Jul 11 12:40:38 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 12:40:38 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <76940000.1026384038@laptop.kurtis.pp.se> > A customer can have a peer with the default transit, which aggregates the > adresspace from the customer, and the customer can have other peerings > via some ix:es, and the customer could perform transit to/from the ix:es > to the default transit, in this scenario the customer MUST have a public > AS, which you will not see in the public space, since removing private > AS in the AS-path will result in somewhat unpredictable behaviour if there > are several private AS involved at the customer premises. Yes, but this still makes the AS publicly visible. Best regards, - kurtis - From ripe-lir-wg at chriss.net Thu Jul 11 13:23:59 2002 From: ripe-lir-wg at chriss.net (Christopher Sharp) Date: Thu, 11 Jul 2002 11:23:59 +0000 Subject: [lir-wg] AS Number Policy In-Reply-To: <686000000.1026379917@laptop.kurtis.pp.se> References: <686000000.1026379917@laptop.kurtis.pp.se> Message-ID: On Thu, 11 Jul 2002 11:31:57 +0200, Kurt Erik Lindqvist wrote: >On a side note - can we also get those major ISPs to filter packets >received from their customers based on the from address? You could try :-) The argument I normally hear is that people want to be lenient to customers but tough on outsiders. Hence bogon filters invariably get placed on ingress peering points rather than customer interfaces of which there are far more. C. From kurtis at kurtis.pp.se Thu Jul 11 13:51:20 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 13:51:20 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <186530000.1026388279@laptop.kurtis.pp.se> > No, it does not, IF the transit decides to aggregate the larger block > that the customer uses adresspace in, and just announce this > larger block for the sake of not polluting the global routing-table, > the customer-as will not be visible in the Internet, just in > lookingglasses via the transit and the customers peeringpartners > lookingglasses. Which again brings us to what is considred public..:) - kurtis - From kurtis at kurtis.pp.se Thu Jul 11 13:53:03 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 13:53:03 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: <686000000.1026379917@laptop.kurtis.pp.se> Message-ID: <189640000.1026388382@laptop.kurtis.pp.se> --On Thursday, July 11, 2002 11:23:59 +0000 Christopher Sharp wrote: > On Thu, 11 Jul 2002 11:31:57 +0200, Kurt Erik Lindqvist > wrote: > >> On a side note - can we also get those major ISPs to filter packets >> received from their customers based on the from address? > > You could try :-) > > The argument I normally hear is that people want to be lenient to > customers but tough on outsiders. Hence bogon filters invariably get > placed on ingress peering points rather than customer interfaces of which > there are far more. Interesting thing is that I am pretty sure that those large ISPs abuse groups are probaly more busy with dealing with the effects of not filtering customers, than their NOCs are with dealing with the effects from not filtering bogon routes... - kurtis - From woeber at cc.univie.ac.at Thu Jul 11 14:00:39 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 11 Jul 2002 14:00:39 +0200 Subject: [lir-wg] AS Number Policy Message-ID: <00A10C6B.CD9397CA.19@cc.univie.ac.at> >I think that this is up to the definition of "publicly visible". If I have >one upstream and several peers, that is to me "public". I see few (no?) >other real reasons for assigning an AS that is not seen through two or more >paths in the global routing table. It is not that rare. For example we do have some universities which have one upstream (us, ACOnet) and peerings with other ISPs (for whatever reason) _but no transit_ from them. Some of them would be "visible" (e.g. those with legacy class B space), others would be proxy aggregated into our /15 and "disappear". But, to come back to another comment: we're discussing details of routing configuration (because that's "easy"?) but I haven't seen any comment yet on my question on price/effort vs. (expected) result ratio (maybe because it's a bit more difficult? ;-). Wilfried. From pekkas at netcore.fi Thu Jul 11 14:00:17 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 11 Jul 2002 15:00:17 +0300 (EEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <189640000.1026388382@laptop.kurtis.pp.se> Message-ID: On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote: > --On Thursday, July 11, 2002 11:23:59 +0000 Christopher Sharp > wrote: > > > On Thu, 11 Jul 2002 11:31:57 +0200, Kurt Erik Lindqvist > > wrote: > > > >> On a side note - can we also get those major ISPs to filter packets > >> received from their customers based on the from address? > > > > You could try :-) > > > > The argument I normally hear is that people want to be lenient to > > customers but tough on outsiders. Hence bogon filters invariably get > > placed on ingress peering points rather than customer interfaces of which > > there are far more. > > > Interesting thing is that I am pretty sure that those large ISPs abuse > groups are probaly more busy with dealing with the effects of not filtering > customers, than their NOCs are with dealing with the effects from not > filtering bogon routes... In addition, I fail to see what _leniency_ here is. If the ISP doesn't do ingress filtering from the direction of the customer, it will be done somewhere in the internet anyway. Is it not _better_ for the customer to get the block immediately (e.g. in the case of misconfigured addresses), rather than have to wait for someone distant to do it. They won't be getting return packets _anyway_... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From fredrik at sunet.se Thu Jul 11 13:04:40 2002 From: fredrik at sunet.se (Fredrik Widell) Date: Thu, 11 Jul 2002 13:04:40 +0200 (CEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <76940000.1026384038@laptop.kurtis.pp.se> Message-ID: On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote: > > > A customer can have a peer with the default transit, which aggregates the > > adresspace from the customer, and the customer can have other peerings > > via some ix:es, and the customer could perform transit to/from the ix:es > > to the default transit, in this scenario the customer MUST have a public > > AS, which you will not see in the public space, since removing private > > AS in the AS-path will result in somewhat unpredictable behaviour if there > > are several private AS involved at the customer premises. > > Yes, but this still makes the AS publicly visible. No, it does not, IF the transit decides to aggregate the larger block that the customer uses adresspace in, and just announce this larger block for the sake of not polluting the global routing-table, the customer-as will not be visible in the Internet, just in lookingglasses via the transit and the customers peeringpartners lookingglasses. > > Best regards, > > - kurtis - > -- Regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 ------------------------------------------------------- From gert at space.net Thu Jul 11 15:07:23 2002 From: gert at space.net (Gert Doering) Date: Thu, 11 Jul 2002 15:07:23 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: ; from ripe-lir-wg@chriss.net on Thu, Jul 11, 2002 at 11:23:59AM +0000 References: <686000000.1026379917@laptop.kurtis.pp.se> Message-ID: <20020711150723.T13357@Space.Net> Hi, On Thu, Jul 11, 2002 at 11:23:59AM +0000, Christopher Sharp wrote: > The argument I normally hear is that people want to be lenient to customers but > tough on outsiders. Hence bogon filters invariably get placed on ingress > peering points rather than customer interfaces of which there are far more. Crappy argument. You can't do reverse path filtering on peering points (after all, most of the world's IP range is "outside"). The *only* thing that works is strict anti-spoofing filters on all customer lines. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45809 (45931) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From stephenb at uk.uu.net Thu Jul 11 15:33:32 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 11 Jul 2002 14:33:32 +0100 Subject: [lir-wg] A quick question. Message-ID: <033201c228df$8ce633b0$2e04bf3e@eu.frd.uu.net> HI I have a question about the RIPE meetings. Due to the nature of the business we are all in at the moment (myself probably more than others ATM), would it not be possable the webcast the RIPE meetings allowing input from outside via phone, email, or other means. The reason i ask this is that the meetings are open to all IF and its a big IF you can attend the meeting in the exotic locations we have met in the past. I am not against the meetings moving about and a meeting in Amsterdam will be just as hard to get to for some one in North Africa as a meeting in North Africa for those in Amsterdam. What i am asking is could we make it more accessable to those who for what ever reason (ahem) can not make the meeting, otherwise it might not have the coverage and diversity of people having input. Just a thought. Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE From wtremmel at vianetworks.com Thu Jul 11 15:59:32 2002 From: wtremmel at vianetworks.com (Wolfgang Tremmel, WT5-RIPE) Date: Thu, 11 Jul 2002 15:59:32 +0200 Subject: [lir-wg] A quick question. In-Reply-To: <033201c228df$8ce633b0$2e04bf3e@eu.frd.uu.net> Message-ID: I second that. It's quite hard to argument why a meeting in Rhodes is really a *meeting* and not a short holiday on companies expense... The experience with IETF shows that it is possible to multicast the meeting (perhaps for the next one it is a little bit of short notice), although I think it is not possible to really "participate" that way. best regards, Wolfgang WT5-RIPE > -----Original Message----- > From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of > Stephen Burley > Sent: Thursday, July 11, 2002 3:34 PM > To: Lir-Wg at Ripe.Net > Subject: [lir-wg] A quick question. > > > > What i am asking is could we make it more accessable to those who for > what ever reason (ahem) can not make the meeting, otherwise it might not > have the coverage and diversity of people having input. Just a thought. > > Regards, > > Stephen Burley > WorldCom EMEA Hostmaster > SB855-RIPE From ripe-lir-wg at chriss.net Thu Jul 11 16:47:51 2002 From: ripe-lir-wg at chriss.net (Christopher Sharp) Date: Thu, 11 Jul 2002 14:47:51 +0000 Subject: [lir-wg] AS Number Policy In-Reply-To: <20020711150723.T13357@Space.Net> References: <686000000.1026379917@laptop.kurtis.pp.se> <20020711150723.T13357@Space.Net> Message-ID: On Thu, 11 Jul 2002 15:07:23 +0200, Gert Doering wrote: >On Thu, Jul 11, 2002 at 11:23:59AM +0000, Christopher Sharp wrote: >> The argument I normally hear is that people want to be lenient to customers but >> tough on outsiders. Hence bogon filters invariably get placed on ingress >> peering points rather than customer interfaces of which there are far more. > >Crappy argument. You can't do reverse path filtering on peering points >(after all, most of the world's IP range is "outside"). > >The *only* thing that works is strict anti-spoofing filters on all >customer lines. We all know that it's a crappy argument, but lots of people try using it. Especially those who have large legacy implementations that either don't have or don't support filters on customer lines. Over the years I have seen a lot of providers who let their customers advertise whatever they want into their internal route tables. I've seen customers of "tier-1" providers with multiple circuits routing RFC1918 space between their offices, across 1000s of miles over the providers cloud. Sure it's caught by egress filters on the ISPs borders (in most cases) and most ISPs filter their new customer interfaces, but there are plenty of legacy configurations out there that the older players are frightened to break. Bogon filtering at ingress points is something that people are doing. There might be plenty of other things they should be doing, but many people aren't. In my experience customer line filters (where they exist) are rarely updated, whilst ingress bogon filters on peering connections are well maintained. If you want to encourage people to add filters and maintain them responsibly then this is the best place for them. Filtering these renegade addresses should only be a last resort. It will make re-allocation of them a lot harder. The threat of such filters would be an excellent incentive for people to return ASNs and address space when requested though. C. From PLu at cw.net Thu Jul 11 17:02:29 2002 From: PLu at cw.net (Lu, Ping) Date: Thu, 11 Jul 2002 11:02:29 -0400 Subject: [lir-wg] AS Number Policy Message-ID: > -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis at kurtis.pp.se] > Sent: Thursday, July 11, 2002 6:41 AM > To: lir-wg at ripe.net > Subject: RE: [lir-wg] AS Number Policy > > > > > A customer can have a peer with the default transit, which > aggregates the > > adresspace from the customer, and the customer can have > other peerings > > via some ix:es, and the customer could perform transit > to/from the ix:es > > to the default transit, in this scenario the customer MUST > have a public > > AS, which you will not see in the public space, since > removing private > > AS in the AS-path will result in somewhat unpredictable > behaviour if there > > are several private AS involved at the customer premises. > > Yes, but this still makes the AS publicly visible. > > Best regards, > > - kurtis - > As we already seen some real examples, the correct USED ASN will only be seen from their upstream (it is public no matter what) but not outside to other peers (may due to CIDR, may due to inactive route). This has nothing to do with private ASN but make it impossible to enforce the proposed policy just by looking at the RIS. I agree that RIPE NCC need to have an ASN revoke policy but just can NOT based on the RIS info only. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu at cw.net From kurtis at kurtis.pp.se Thu Jul 11 17:23:57 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 17:23:57 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <45780000.1026401037@laptop.kurtis.pp.se> > If the ISP doesn't do ingress filtering from the direction of the > customer, it will be done somewhere in the internet anyway. Is it not > _better_ for the customer to get the block immediately (e.g. in the case > of misconfigured addresses), rather than have to wait for someone distant > to do it. They won't be getting return packets _anyway_... Well, if all those packets get filtered somewhere else in the network, that part has surely never been in the path to the networks I worked for. We have always seen DoS attacks with forged source addresses. ...and I think that having the customer wait is better than have a few networks cripple under load. - kurtis - From kurtis at kurtis.pp.se Thu Jul 11 17:26:04 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 17:26:04 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: <00A10C6B.CD9397CA.19@cc.univie.ac.at> References: <00A10C6B.CD9397CA.19@cc.univie.ac.at> Message-ID: <50150000.1026401164@laptop.kurtis.pp.se> > For example we do have some universities which have one upstream (us, > ACOnet) and peerings with other ISPs (for whatever reason) _but no > transit_ from them. > > Some of them would be "visible" (e.g. those with legacy class B space), > others would be proxy aggregated into our /15 and "disappear". Which is fine. They are "public" in the sense that a "large" number of AS:es see them. > But, to come back to another comment: we're discussing details of > routing configuration (because that's "easy"?) but I haven't seen any > comment yet on my question on price/effort vs. (expected) result ratio > (maybe because it's a bit more difficult? ;-). I am not sure this has anything to do with routing configuration vs pricing. It has to do with application of AS-numbers and who are entiled to get/have one. - kurtis - From kurtis at kurtis.pp.se Thu Jul 11 17:39:41 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 17:39:41 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: <686000000.1026379917@laptop.kurtis.pp.se> <20020711150723.T13357@Space.Net> Message-ID: <80160000.1026401981@laptop.kurtis.pp.se> > We all know that it's a crappy argument, but lots of people try using it. > Especially those who have large legacy implementations that either don't > have or don't support filters on customer lines. I agree with you. Still, the common argument is that it's to complex to maintain and to expensive to install. But again, I am sure the cost of dealing with the effects is close to the same amount. But few people realise this. > Over the years I have seen a lot of providers who let their customers > advertise whatever they want into their internal route tables. I've seen Well that is one thing. And that is plain stupidity of the operator who are putting their own network at risk. Starting to do sourceed packet filtering on ingress from customers is something else, and probably a larger task and problem. Best regards, - kurtis - From gert at space.net Thu Jul 11 17:47:13 2002 From: gert at space.net (Gert Doering) Date: Thu, 11 Jul 2002 17:47:13 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: <80160000.1026401981@laptop.kurtis.pp.se>; from kurtis@kurtis.pp.se on Thu, Jul 11, 2002 at 05:39:41PM +0200 References: <686000000.1026379917@laptop.kurtis.pp.se> <20020711150723.T13357@Space.Net> <80160000.1026401981@laptop.kurtis.pp.se> Message-ID: <20020711174713.H13357@Space.Net> Hi, On Thu, Jul 11, 2002 at 05:39:41PM +0200, Kurt Erik Lindqvist wrote: > > We all know that it's a crappy argument, but lots of people try using it. > > Especially those who have large legacy implementations that either don't > > have or don't support filters on customer lines. > > I agree with you. Still, the common argument is that it's to complex to > maintain and to expensive to install. With more recent vendor software versions, it's nearly always possible to automatically filter single-homed customers ("ip verify unicast reverse" in Cisco speak). It's *easy*, and maintenance effort is zero. For multi-homed customers, you need plain old access-lists, which isn' that easy, but hopefully *they* will do anti-spoofing filters then (assuming a higher clue level for multi-homing customers). > But again, I am sure the cost of > dealing with the effects is close to the same amount. But few people > realise this. Tell 'em about it, repeat it again and again... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45809 (45931) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From ripe-lir-wg at chriss.net Thu Jul 11 19:06:30 2002 From: ripe-lir-wg at chriss.net (Christopher Sharp) Date: Thu, 11 Jul 2002 17:06:30 +0000 Subject: [lir-wg] AS Number Policy In-Reply-To: <80160000.1026401981@laptop.kurtis.pp.se> References: <686000000.1026379917@laptop.kurtis.pp.se> <20020711150723.T13357@Space.Net> <80160000.1026401981@laptop.kurtis.pp.se> Message-ID: On Thu, 11 Jul 2002 17:39:41 +0200, Kurt Erik Lindqvist wrote: >> We all know that it's a crappy argument, but lots of people try using it. >> Especially those who have large legacy implementations that either don't >> have or don't support filters on customer lines. > >I agree with you. Still, the common argument is that it's to complex to >maintain and to expensive to install. But again, I am sure the cost of >dealing with the effects is close to the same amount. But few people >realise this. I'm not entirely convinced that everyone has this choice. Some providers have legacy access kit that simply doesn't support filters on a per-interface basis. Many are starting to filter on ingress/egress to each PoP which is a good start. Part of the problem is raw router processing power. If you've only got enough processing power to filter inbound *or* outbound, you're more likely to want to filter inbound (to stop your customers being DoSed) than outbound. Providers are filtering outbound, but it's inbound filters that have all the effort invested in them. They also tend to be a lot more dynamic thus are a lot better maintained. C. From pekkas at netcore.fi Thu Jul 11 20:11:26 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 11 Jul 2002 21:11:26 +0300 (EEST) Subject: [lir-wg] AS Number Policy In-Reply-To: <45780000.1026401037@laptop.kurtis.pp.se> Message-ID: On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote: > > > If the ISP doesn't do ingress filtering from the direction of the > > customer, it will be done somewhere in the internet anyway. Is it not ^^^ > > _better_ for the customer to get the block immediately (e.g. in the case > > of misconfigured addresses), rather than have to wait for someone distant > > to do it. They won't be getting return packets _anyway_... Oops, I made a drastic typo when editing the message. Cut off that 'not', so we agree. > Well, if all those packets get filtered somewhere else in the network, that > part has surely never been in the path to the networks I worked for. We > have always seen DoS attacks with forged source addresses. We perform additional form of filtering at our border routers to upstreams and peerings (for ingress, check that our addresses are not listed; for egress, we drop packets with private and other martian addresses just to be sure). This does not, naturally help with identifying spoofed DoS attacks reliably. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From hostmaster at knowtion.net Thu Jul 11 18:03:16 2002 From: hostmaster at knowtion.net (Knowtion Hostmaster Role Account) Date: Thu, 11 Jul 2002 17:03:16 +0100 Subject: [lir-wg] Re: NCC#2002069654 HMQUESTION References: <200206170937.g5H9bHA28671@birch.ripe.net> <200207041524.g64FOpH20331@cow.ripe.net> <01ab01c22376$23ed1bd0$2728a8c0@carpenter> <200207111513.g6BFDNP25937@cow.ripe.net> Message-ID: <000401c228f4$78028ec0$78cb87d4@walrus> > You are correct to say that you can not remove a maintainer from a > object without adding a new one. > > The attribute in the object is mandatory, the AS number > AS9179 is part of the from the RIPE NCC, and if correct the > maintainer is being maintained by yourselves. How can I phrase this better ? AS9179-MNT (me / my company) is the current but out-of-date maintainer on an object. Without deleting the object (as it is not relly mine) how can I cease being associated with it ? I (AS9179-MNT) no longer am the maintainer of various objects that really belong to the company X in the UK. My company has not been associated with them or provided services to them for sometime. Is it good and recommended practice therefore for me to just delete the objects - this may affect someones service ? cc'ed to lir-wg in case anyone has a better idea... Petr From jacek_blocki at hp.com Thu Jul 11 20:46:17 2002 From: jacek_blocki at hp.com (BLOCKI,JACEK (HP-Poland,ex1)) Date: Thu, 11 Jul 2002 20:46:17 +0200 Subject: [lir-wg] AS Number Policy Message-ID: <952C79D45561D4119FCE00D0B708C8E004E6F4AC@lem.poland.hp.com> If we need AS revocation policy and cannot agree on usage auditing based on technical wisdom, we can consider some old fashioned administrative measures such as AS subscription fee paid to RIR. Make it 1$/year AS maintenance fee paid to RIR (similar to LIR fee). It will at least allow to identify ASes assigned to terminated organizations. Feel free to flame me ;-) Regards, Jacek From kurtis at kurtis.pp.se Thu Jul 11 23:42:59 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 11 Jul 2002 23:42:59 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: <686000000.1026379917@laptop.kurtis.pp.se> <20020711150723.T13357@Space.Net> <80160000.1026401981@laptop.kurtis.pp.se> Message-ID: <328750000.1026423779@laptop.kurtis.pp.se> > I'm not entirely convinced that everyone has this choice. Some providers > have legacy access kit that simply doesn't support filters on a > per-interface basis. Many are starting to filter on ingress/egress to > each PoP which is a good start. I built and ISP with everything from 25xx to GSRs. I seriously doubt someone has PE devices that can't forward the packets AND do rudimentary filtering on addresses. But maybe you are right...then again, as you say - filtering per POP is as good. Actually it doesn't matter that much where you filter as long as you do it right - AND.... > Part of the problem is raw router processing power. If you've only got ...you have the CPU cycles... > enough processing power to filter inbound *or* outbound, you're more > likely to want to filter inbound (to stop your customers being DoSed) What is "worse"? Your customers beeing DoSes, or you beeing the source of a DoS? Unless we are talking a really small ISP, where there is little difference between ingress and egress routers, this is not that much of an issue. And in that case, I doubt the traffic levels are that high... > than outbound. Providers are filtering outbound, but it's inbound > filters that have all the effort invested in them. They also tend to be > a lot more dynamic thus are a lot better maintained. I don't think any providers are doing outbound source filtering? Not to any large extent, at least that I know of. But I might be wrong...and people dream up the most strange solution nowadays - I am sure that if I where using MPWhateverS this would not be an issue..:) - kurtis - From pfs at cisco.com Fri Jul 12 04:52:53 2002 From: pfs at cisco.com (Philip Smith) Date: Fri, 12 Jul 2002 12:52:53 +1000 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <5.1.0.14.2.20020712124141.04fec008@localhost> At 15:32 10/07/2002 +0000, Christopher Sharp wrote: >This was my suggestion in a nutshell. I believe the most commonly observed >bogon list is maintained by Rob Thomas >(http://www.cymru.com/Documents/bogon-list.html). >draft-iana-special-ipv4-03 is >IANA's most comprehensive list of special use netblocks >(http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt). There is also Bill Manning's list (http://www.ietf.org/internet-drafts/draft-manning-dsua-08.txt). For those of you at the last RIPE meeting, recall that in the Routing Working Group I presented Geoff Huston's proposal that the registries make available a list of their unallocated addresses within their /8 blocks. And I believe all three intend to do that rsn. >This sounds excellent but doesn't cover prefixes IANA have not yet >allocated to >an RIR. This is why I would encourage frequent sharing of this data with the >networking community and especially the maintainers of public bogon lists on >which many people filter. For anyone who is a masochist, I've put together a complete list of all the addresses which are marked in the three registry databases as being unallocated. I use this list for the Routing Report which I post to various lists once a week - and it's the basis for figuring out how much IPv4 address space is left (45.9%). The list is sitting on a router in my lab at the moment - comes to about 1500 entries once they are completely aggregated. Once the registries produce the lists for their blocks, I'll see how easy it would be to merge the two... I could make this publicly available if folks are interested... It would be a BGP feed - exercise left to the reader to figure out how to convert this into a dynamically updated routing and packet filter... ;-) Bigger question would be whether anyone would even want to do it... philip -- From woeber at cc.univie.ac.at Fri Jul 12 19:06:50 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 12 Jul 2002 19:06:50 +0200 Subject: [lir-wg] AS Number Policy Message-ID: <00A10D5F.BDDE97EA.15@cc.univie.ac.at> >> But, to come back to another comment: we're discussing details of >> routing configuration (because that's "easy"?) but I haven't seen any >> comment yet on my question on price/effort vs. (expected) result ratio >> (maybe because it's a bit more difficult? ;-). > >I am not sure this has anything to do with routing configuration vs >pricing. I agree. >It has to do with application of AS-numbers and who are entiled to >get/have one. > >- kurtis - My point is that any attempt to actively reclaim AS#s is going to *cost money*, both on the NCC's end as well as on the community's end. And as many(?) of the ASs which we are presumably talking about have been distributed _before_ the RIRs have been established, there is probably no (longer) a direct AS#/LIR/RIR (i.e. funding) relationship. And even if, we are talking about *our* (the LIRs') money! That's the reason why I'd like to find out about the expected cost, and even more about any educated guess relating to the number of ASs that can likely be reclaimed. And what a difference that number would make in the context of avoiding the introduction of AS#s with more than 16 bits. I hope I was able this time to get my point across ? Wilfried. From krazavi at dpimail.net Sat Jul 13 15:52:54 2002 From: krazavi at dpimail.net (Razavi (Support)) Date: Sat, 13 Jul 2002 18:22:54 +0430 Subject: [lir-wg] need help ! Message-ID: Dear friends Im a new technical admin and new one in ripe knowledge, newly i heard about the new AS# policy but i didnt understant any thing ! is there some one over there to help me or gives me some information about that? wait for your help, Best Regards, --Razavi. From bortzmeyer at gitoyen.net Sat Jul 13 16:07:11 2002 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Sat, 13 Jul 2002 16:07:11 +0200 Subject: [lir-wg] need help ! In-Reply-To: ("Razavi (Support)" 's message of Sat, 13 Jul 2002 18:22:54 +0430) Message-ID: <200207131407.g6DE7BPb005047@ludwigV.sources.org> On Saturday 13 July 2002, at 18 h 22, "Razavi (Support)" wrote: > newly i heard about the new AS# policy ripe-245, I presume. > but i didnt understant any thing ! > is there some one over there to help me or gives me some information about > that? Well, the question is really too vague to be answered. First, let's start with the basics. Do you understand what an AS is? If yes, we'll try to understand together :-) the AS policy. If no, a course in BGP routing is probably a pre-requisite before reading RIPE documentations. From skiv at caravan.ru Mon Jul 15 16:40:14 2002 From: skiv at caravan.ru (Sergey Artjushkin) Date: Mon, 15 Jul 2002 18:40:14 +0400 Subject: [lir-wg] Re-registration of the ip address from the closed LIR to new LIR Message-ID: <3D32DECE.3000908@caravan.ru> Hello colleagues Our company and our partners have faced with one problem. During along time between ours the companies there were very close relations, not only financial, but also technically. Recently a management of both companies have solved to consolidate two companies in one. Both at a financial level and on a technological level. As the technical worker, I can tell, that all clients of our partner pass to us and networks of both companies will be combine. Both companies were registered in RIPE and have received LIR, AS and ip space. As a result of closing the company of our partner LIR registration will be stops and ip addresses will be back. In this connection, technical workers of both companies with horror expect merge of the companies. From one idea, that it is necessary to replace all clients on new ip addresses become badly. Our partners was working during a long time and for this time they have collected the big base of clients. At present, our partners has two blocks of addresses: /19 and /17. Our company will not have not enough ip addresses so we should ask additional ip space. And now my question is: It is theoretically possible to re-register addresses our partners, as belonging to us (new origin in route object and new MNT in network object). How it to make practically? I have sent the letter in RIPE but yet have not received any answer. Thank you for advance for any help. -- With best regards. ------------------------------------------------------------------ Sergey Artjushkin Network Operation Center Phone: +7 (095) 363-22-52 ISP "CARAVAN" Fax: +7 (095) 363-22-52 http://www.caravan.ru From wtremmel at vianetworks.com Tue Jul 16 09:36:12 2002 From: wtremmel at vianetworks.com (Wolfgang Tremmel, WT5-RIPE) Date: Tue, 16 Jul 2002 09:36:12 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: <00A10D5F.BDDE97EA.15@cc.univie.ac.at> Message-ID: It should be *very* easy for RIPE to produce a list of AS numbers assigned and not in the routing tables (of course only for the RIPE area) This first list is just an estimate (see the discussion) but should give us an indication what we are talking about.... best regards, Wolfgang > -----Original Message----- > > > > And as many(?) of the ASs which we are presumably talking about have > been distributed _before_ the RIRs have been established, there is > probably no (longer) a direct AS#/LIR/RIR (i.e. funding) relationship. > And even if, we are talking about *our* (the LIRs') money! > > That's the reason why I'd like to find out about the expected cost, and > even more about any educated guess relating to the number of ASs that > can likely be reclaimed. And what a difference that number would make in > the context of avoiding the introduction of AS#s with more than 16 bits. > > I hope I was able this time to get my point across ? > > Wilfried. From andrei at ripe.net Tue Jul 16 09:49:17 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 16 Jul 2002 09:49:17 +0200 Subject: [lir-wg] Re: NCC#2002069654 HMQUESTION References: <200206170937.g5H9bHA28671@birch.ripe.net> <200207041524.g64FOpH20331@cow.ripe.net> <01ab01c22376$23ed1bd0$2728a8c0@carpenter> <200207111513.g6BFDNP25937@cow.ripe.net> <000401c228f4$78028ec0$78cb87d4@walrus> Message-ID: <3D33CFFD.9060209@ripe.net> Dear Peter, Knowtion Hostmaster Role Account wrote: >>You are correct to say that you can not remove a maintainer from a >> > > >>object without adding a new one. >> >>The attribute in the object is mandatory, the AS number >>AS9179 is part of the from the RIPE NCC, and if correct the >>maintainer is being maintained by yourselves. >> > > How can I phrase this better ? > > AS9179-MNT (me / my company) is the current but out-of-date maintainer on an > object. Without deleting the object (as it is not relly mine) how can I > cease being associated with it ? > > I (AS9179-MNT) no longer am the maintainer of various objects that really > belong to the company X in the UK. My company has not been associated with > them or provided services to them for sometime. > > Is it good and recommended practice therefore for me to just delete the > objects - this may affect someones service ? > It depends on the nature of the objects. Deletion of the objects that represent resources that don't exist anymore (non announced routes, non referenced person objects, etc.) means a cleanup and is recommended and appreciated. However in case the resource does exist I would suggest changing the maintenance of this object to the real holder of the resource. > cc'ed to lir-wg in case anyone has a better idea... > > Petr > Regards, Andrei Robachevsky DB Group RIPE NCC From ncc at ripe.net Tue Jul 16 10:01:51 2002 From: ncc at ripe.net (RIPE NCC) Date: Tue, 16 Jul 2002 10:01:51 +0200 Subject: [lir-wg] Re: NCC#2002069654 HMQUESTION In-Reply-To: <000401c228f4$78028ec0$78cb87d4@walrus>; from Knowtion Hostmaster Role Account on Thu, 11 Jul 2002 17:03:16 +0100 References: <200206170937.g5H9bHA28671@birch.ripe.net> <200207041524.g64FOpH20331@cow.ripe.net> <01ab01c22376$23ed1bd0$2728a8c0@carpenter> <200207111513.g6BFDNP25937@cow.ripe.net> <000401c228f4$78028ec0$78cb87d4@walrus> Message-ID: <200207160801.g6G81pb12469@cow.ripe.net> Dear Peter, Thank you for your reply. In answer to your questions; * AS9179-MNT (me / my company) is the current but out-of-date maintainer on an * object. Without deleting the object (as it is not relly mine) how can I * cease being associated with it ? You could consider contacting the relevant contacts related to the objects in question. They may have their own maintainer they want to place on the objects, in which case you could send an update with the new maintainer as the mnt-by: attribute. If need be the following URL provides information on the creation of a new maintainer: http://www.ripe.net/ripencc/pub-services/db/Maintainer_Creation_Procedure.html Please contact me if you require further assistance. Kind regards, Winston Schenkers RIPE NCC On Thu, 11 Jul 2002 17:03:16 +0100, Knowtion Hostmaster Role Account wrote: * > You are correct to say that you can not remove a maintainer from a * * > object without adding a new one. * > * > The attribute in the object is mandatory, the AS number * > AS9179 is part of the from the RIPE NCC, and if correct the * > maintainer is being maintained by yourselves. * * How can I phrase this better ? * * AS9179-MNT (me / my company) is the current but out-of-date maintainer on an * object. Without deleting the object (as it is not relly mine) how can I * cease being associated with it ? * * I (AS9179-MNT) no longer am the maintainer of various objects that really * belong to the company X in the UK. My company has not been associated with * them or provided services to them for sometime. * * Is it good and recommended practice therefore for me to just delete the * objects - this may affect someones service ? * * cc'ed to lir-wg in case anyone has a better idea... * * Petr * From beri at kpnqwest.net Mon Jul 15 17:06:41 2002 From: beri at kpnqwest.net (Berislav Todorovic) Date: Mon, 15 Jul 2002 17:06:41 +0200 (CEST) Subject: [lir-wg] Re-registration of the ip address from the closed LIR to new LIR In-Reply-To: <3D32DECE.3000908@caravan.ru> Message-ID: On Mon, 15 Jul 2002, Sergey Artjushkin wrote: >> During along time between ours the companies there were very close >> relations, not only financial, but also technically. Recently a >> management of both companies have solved to consolidate two companies >> in one. Both at a financial level and on a technological level. >> [snip] Hi Sergey, You should read the (recently published) ripe-241 document. Chapter 2.6 contains the answer to your question. Regards, Beri From beri at kpnqwest.net Tue Jul 16 11:20:51 2002 From: beri at kpnqwest.net (Berislav Todorovic) Date: Tue, 16 Jul 2002 11:20:51 +0200 (CEST) Subject: [lir-wg] AS Number Policy In-Reply-To: Message-ID: On Tue, 16 Jul 2002, Wolfgang Tremmel, WT5-RIPE wrote: >> It should be *very* easy for RIPE to produce a list of AS numbers >> assigned and not in the routing tables (of course only for the RIPE >> area) Kinda out of topic, but still wondering - I just downloaded: ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.aut-num.gz Now, I know that unassigned AS numbers hanging around in the routing tables are nothing new. However, if they are properly registered within RIPE DB and noone notices the forgery - that's worrying: After processing it I've got the list of 5656 AS numbers assigned by RIPE NCC (not that difficult, agree). However, the list contacts two very interesting entries: AS55000 and AS55555! IANA-reserved ASN range! Let's examine the first one - it has an aut-num, route object and a proper route in the global routing table. Appears to be single-homed. aut-num: AS55000 as-name: MIPT-NET descr: MIPT-TELECOM-NET [snip] route: 81.5.64.0/20 descr: MIPT-TELECOM-NET origin: AS55000 [snip] * i81.5.64.0/20 134.222.249.118 80 50 3561 8342 8342 8810 8810 5467 55000 i The other one was a bit more "honest" - they admitted they are "fake" and they don't pollute the global routing table. They also don't have any route objects. Still, an ugly entry exists in the RIPE DB: aut-num: AS55555 as-name: AS55555 descr: fake AS descr: Kiev, Ukraine [snip] Are we going to stick with the rule that RIPE NCC people cannot modify the RIPE DB and tolerate the offenders? Just wondering ... Regards, Beri From andrei at ripe.net Tue Jul 16 13:20:36 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 16 Jul 2002 13:20:36 +0200 Subject: [lir-wg] AS Number Policy References: Message-ID: <3D340184.2080403@ripe.net> Dear Berislav, Colleagues, Berislav Todorovic wrote: [...] > Now, I know that unassigned AS numbers hanging around in the routing tables > are nothing new. However, if they are properly registered within RIPE DB > and noone notices the forgery - that's worrying: [...] > > Are we going to stick with the rule that RIPE NCC people cannot modify the > RIPE DB and tolerate the offenders? Just wondering ... > I just wanted to note that though we have such general rule we also have exceptions. Especially when the data in the database conflicts with the information in the Registration Services. Of course our main concern is regarding the space distributed by the RIPE NCC. Speaking of the quality of data in the RIPE Database in general, we are working towards making the database more restrictive to reject bogus records. We also run database consistency projects to help people to keep their records up to date. Also, as you know, we perform massive clean-ups if the community have requested such actions. That, for instance, happened to unreferenced person objects; we plan a cleanup of non valid "auth:" fields in mntner objects. In my opinion such actions are more favourable as they get community consensus and require much less resources per inconsistency than a single clean-up. We are also discussing some ideas of how to allow the holders of the address or ASN space to perform necessary clean-ups within their space without requesting the RIPE NCC to do this. > Regards, > Beri > Regards, Andrei Robachevsky DB Group RIPE NCC From hostmaster at knowtion.net Tue Jul 16 11:00:03 2002 From: hostmaster at knowtion.net (Knowtion Hostmaster Role Account) Date: Tue, 16 Jul 2002 10:00:03 +0100 Subject: [lir-wg] Re: NCC#2002069654 HMQUESTION References: <200206170937.g5H9bHA28671@birch.ripe.net> <200207041524.g64FOpH20331@cow.ripe.net> <01ab01c22376$23ed1bd0$2728a8c0@carpenter> <200207111513.g6BFDNP25937@cow.ripe.net> <000401c228f4$78028ec0$78cb87d4@walrus> <200207160801.g6G81pb12469@cow.ripe.net> Message-ID: <001f01c22ca7$5df8c420$7bcb87d4@walrus> > You could consider contacting the relevant contacts related to the objects > in question. They may have their own maintainer they want to place on the > objects, in which case you could send an update with the new maintainer as the > mnt-by: attribute. They do not respond. Let us assume that the actual contacts are either 'stupid' or 'hostile'. What then ? Peter > If need be the following URL provides information on the creation of a new > maintainer: > > > http://www.ripe.net/ripencc/pub-services/db/Maintainer_Creation_Procedure.ht ml > > Please contact me if you require further assistance. > > > Kind regards, > > Winston Schenkers > RIPE NCC > > On Thu, 11 Jul 2002 17:03:16 +0100, Knowtion Hostmaster Role Account wrote: > * > You are correct to say that you can not remove a maintainer from a > * > * > object without adding a new one. > * > > * > The attribute in the object is mandatory, the AS number > * > AS9179 is part of the from the RIPE NCC, and if correct the > * > maintainer is being maintained by yourselves. > * > * How can I phrase this better ? > * > * AS9179-MNT (me / my company) is the current but out-of-date maintainer on an > * object. Without deleting the object (as it is not relly mine) how can I > * cease being associated with it ? > * > * I (AS9179-MNT) no longer am the maintainer of various objects that really > * belong to the company X in the UK. My company has not been associated with > * them or provided services to them for sometime. > * > * Is it good and recommended practice therefore for me to just delete the > * objects - this may affect someones service ? > * > * cc'ed to lir-wg in case anyone has a better idea... > * > * Petr > * > From pfs at cisco.com Wed Jul 17 04:08:48 2002 From: pfs at cisco.com (Philip Smith) Date: Wed, 17 Jul 2002 12:08:48 +1000 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <5.1.0.14.2.20020717115902.03bb7ec0@lint.cisco.com> At 11:20 16/07/2002 +0200, Berislav Todorovic wrote: >Now, I know that unassigned AS numbers hanging around in the routing tables >are nothing new. However, if they are properly registered within RIPE DB >and noone notices the forgery - that's worrying: I've noticed, from the day it appeared - I highlight all "illegal" AS announcements in my weekly routing report (sent to the routing-wg amongst lots of other places). It seems as though the RIPE NCC couldn't care less though about the forgery, and that is alarming given that address and AS allocation is supposed to be their function. On the otherhand, if this is a real allocation, can someone from the NCC please announce to the community what new AS block this is from, and correct the IANA delegation file... thanks! philip -- From manuel at ripe.net Wed Jul 17 12:22:48 2002 From: manuel at ripe.net (Manuel Valente) Date: Wed, 17 Jul 2002 12:22:48 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: <00A10D5F.BDDE97EA.15@cc.univie.ac.at> Message-ID: <20020717122248.4a7e44a7.manuel@ripe.net> Greetings, On Tue, 16 Jul 2002 09:36:12 +0200 "Wolfgang Tremmel, WT5-RIPE" wrote: > It should be *very* easy for RIPE to produce a list > of AS numbers assigned and not in the routing tables > (of course only for the RIPE area) If people in the community show interest for this data, the RIPE NCC is ready to publish it. It should be noted that this data would be extracted from the Routing Information Registry Project, with the limitations that were already highlighted somewhere in this thread - see also http://ris.ripe.net/ > This first list is just an estimate (see the discussion) but > should give us an indication what we are talking about.... Indeed. Regards, -- Manuel Valente - Software Manager - RIPE NCC "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." (Antoine de Saint-Exupery) From kurtis at kurtis.pp.se Wed Jul 17 16:12:56 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 17 Jul 2002 16:12:56 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: <5.1.0.14.2.20020717115902.03bb7ec0@lint.cisco.com> References: <5.1.0.14.2.20020717115902.03bb7ec0@lint.cisco.com> Message-ID: <659990000.1026915176@laptop.kurtis.pp.se> --On Wednesday, July 17, 2002 12:08:48 +1000 Philip Smith wrote: > It seems as though the RIPE NCC couldn't care less though about the > forgery, and that is alarming given that address and AS allocation is > supposed to be their function. What is ofcourse interesting as well is - what can the NCC do to stop this or prevent it from happening in the future? They can send angry emails and remove the objects from the database (which ofcourse would be a good start...:) ), but they can't prevent the AS:es from being routed. What is really interesting is that some upstream is actually accepting these AS:es as peers... - kurtis - From andrei at ripe.net Wed Jul 17 17:16:11 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 17 Jul 2002 17:16:11 +0200 Subject: [lir-wg] Draft document "New Values of the 'status:' attribute for inet6num Objects" is available Message-ID: <3D358A3B.6060205@ripe.net> Dear Colleagues, [apologies for duplicate messages] The draft document "New Values of the 'status:' attribute for inet6num Objects" is available on the RIPE NCC website at: http://www.ripe.net/ripencc/draft-documents/ This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. The deadline for comments and suggestions is Wednesday, 24th July. After incorporating any suggested changes to the document the final document will be published as a RIPE Document. On Thursday, 25th July, subject to any additional comments, the described Database functionality will be put in to practice. Please send your comments and suggestions to . Regards, Andrei Robachevsky RIPE NCC From anna.skyllberg at tele2.se Thu Jul 18 01:01:18 2002 From: anna.skyllberg at tele2.se (anna.skyllberg at tele2.se) Date: Thu, 18 Jul 2002 01:01:18 +0200 Subject: [lir-wg] Anna Skyllberg/Tele2 is out of the office. Message-ID: I will be out of the office starting 2002-06-21 and will not return until 2002-08-12. I will respond to your message when I return. From wtremmel at vianetworks.com Thu Jul 18 09:54:44 2002 From: wtremmel at vianetworks.com (Wolfgang Tremmel, WT5-RIPE) Date: Thu, 18 Jul 2002 09:54:44 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: <659990000.1026915176@laptop.kurtis.pp.se> Message-ID: > > What is really interesting is that some upstream is actually accepting > these AS:es as peers... perhaps RIPE should bash these upstreams.... one after the other down the AS path, until one takes action..... Wolfgang From kurtis at kurtis.pp.se Thu Jul 18 11:26:28 2002 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 18 Jul 2002 11:26:28 +0200 Subject: [lir-wg] AS Number Policy In-Reply-To: References: Message-ID: <62520000.1026984388@laptop.kurtis.pp.se> >> >> What is really interesting is that some upstream is actually accepting >> these AS:es as peers... > > perhaps RIPE should bash these upstreams.... one after the other down > the AS path, until one takes action..... Hmm, RIPE NCC could ofcourse create entries in the db to block all their announcements until they fixed this...no wait that would require people to actually understand and use filters in the first place...:( - kurtis - From randy at psg.com Thu Jul 18 12:26:28 2002 From: randy at psg.com (Randy Bush) Date: Thu, 18 Jul 2002 19:26:28 +0900 Subject: [lir-wg] AS Number Policy References: <659990000.1026915176@laptop.kurtis.pp.se> Message-ID: >> What is really interesting is that some upstream is actually accepting >> these AS:es as peers... > perhaps RIPE should bash these upstreams.... one after the other down > the AS path, until one takes action..... why not just report them to the net police? From pieterjan at itn.skynet.be Thu Jul 18 11:27:05 2002 From: pieterjan at itn.skynet.be (D'HERTOG Pieterjan) Date: Thu, 18 Jul 2002 11:27:05 +0200 Subject: [lir-wg] rfc-ignorant.org Message-ID: Did someone else receive such emails from rfc-ignorant.org? : > -----Original Message----- > From: > bounce-ripe+194.78.245.172_ripe_skynet.be at beatrice.rutgers.edu > > [mailto:bounce-ripe+194.78.245.172_ripe_skynet.be at beatrice.rut > gers.edu] On Behalf Of > reply-ripe+194.78.245.172_ripe_skynet.be at beatrice.rutgers.edu > Sent: donderdag 18 juli 2002 0:18 > To: submit-ipwhois at rfc-ignorant.org > Cc: ripe at skynet.be; noc at skynet.be > Subject: 194.78.245.172/30 > > > > The IP address block 194.78.245.172/30 has a WHOIS contact, > RD3539-RIPE, which lacks an email address. This CIDR block is > therefore subject to listing on the blacklist > ipwhois.rfc-ignorant.org (see http://www.rfc-ignorant.org). > This email is CCd to the following locatable responsible parties: > ripe at skynet.be > noc at skynet.be > See below for the WHOIS data. > > -Allen > > inetnum: 194.78.245.172 - 194.78.245.175 > netname: SKY-1869366 > descr: Friends Of The Earth > country: BE > admin-c: RD3539-RIPE > tech-c: SN2068-RIPE > rev-srv: ns1.skynet.be > rev-srv: ns2.skynet.be > rev-srv: ns3.skynet.be > rev-srv: ns4.skynet.be > status: ASSIGNED PA > mnt-by: SKYNETBE-MNT > changed: ripe at skynet.be 20010806 > source: RIPE > > role: Skynet NOC administrators > address: Belgacom Skynet SA/NV > address: rue colonel Bourg 124 > address: B-1140 Brussels > address: Belgium > phone: +3227061311 > fax-no: +3227269311 > email: ripe at skynet.be > admin-c: JFS1-RIPE > tech-c: PDH16-RIPE > nic-hdl: SN2068-RIPE > remarks: ------------------------------------------ > remarks: Abuse notifications to: abuse at skynet.be > remarks: Network problems to: noc at skynet.be > remarks: Peering requests to: peering at skynet.be > remarks: ------------------------------------------ > notify: noc at skynet.be > mnt-by: SKYNETBE-MNT > changed: ripe at skynet.be 20010907 > source: RIPE > > person: Roger Doiron > address: Friends Of The Earth > address: Rue Blanche 29 > address: 1060 Bruxelles > phone: +32 25420180 > nic-hdl: RD3539-RIPE > remarks: SKYNET-SKYNET-1602730 > notify: noc at skynet.be > mnt-by: SKYNETBE-MNT > changed: Ripe at skynet.be 20010802 > source: RIPE > > > -- > Allen Smith http://cesario.rutgers.edu/easmith/ > September 11, 2001 A Day That Shall Live In Infamy II > "They that can give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." - > Benjamin Franklin > --- Pieterjan d'Hertog, Senior Network Engineer Belgacom Skynet NV/SA, 2 Rue Carli, B-1140 Brussels Phone +3227061311 Fax +3227061150 http://www.skynet.be PGP fingerprint: D9AB CD6A 2A78 73CC 68BF 0AFA 8FB3 5821 E4BB 9D2E From mally at ripe.net Thu Jul 18 13:24:02 2002 From: mally at ripe.net (Mally Mclane) Date: Thu, 18 Jul 2002 13:24:02 +0200 Subject: [lir-wg] rfc-ignorant.org In-Reply-To: Message-ID: On Thu, 18 Jul 2002, D'HERTOG Pieterjan wrote: > Did someone else receive such emails from rfc-ignorant.org? : You may find apnic's APOPs list and the rfc-ignorant discussion list helpful for background: http://www.apnic.net/mailing-lists/apops/archive/2001/10/msg00008.html http://lists.megacity.org/pipermail/rfci-discuss/2001-October/000054.html Do feel free to make your opinion about them and the service they offer. We personally haven't been contacted by them (afaik), but we often get others threatening to submit us to them. Cheers, Mally From woeber at cc.univie.ac.at Thu Jul 18 13:54:24 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 18 Jul 2002 13:54:24 +0200 Subject: [lir-wg] rfc-ignorant.org Message-ID: <00A111EB.16A430DA.5@cc.univie.ac.at> > The IP address block 194.78.245.172/30 has a WHOIS contact, > RD3539-RIPE, which lacks an email address. > wripe -t person % This is the RIPE Whois server. % The objects are in RPSL format. % Please visit http://www.ripe.net/rpsl for more information. person: [mandatory] [single] [lookup key] [ ... ] e-mail: [optional] [multiple] [lookup key] [ ... ] ^^^^^^^^ And if we would make it required (I would not object, btw!) - how about registering the.pope at holy.see.vt ;-) When and how would we check the usefulness of the eMail entry? And how to deal with race conditions for new sites/networks? Puzzled. Wilfried. From peter.galbavy at knowtion.net Thu Jul 18 14:08:56 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Thu, 18 Jul 2002 13:08:56 +0100 Subject: [lir-wg] rfc-ignorant.org References: <00A111EB.16A430DA.5@cc.univie.ac.at> Message-ID: <013401c22e53$ef196f60$2728a8c0@carpenter> > e-mail: [optional] [multiple] [lookup key] > [ ... ] ^^^^^^^^ > > And if we would make it required (I would not object, btw!) - > how about registering the.pope at holy.see.vt ;-) Just demonstrates that their domain name is apt. If only the wrong way around. Bad idiots, write out 100 times: "I am NOT holier than thou." Peter From piet at skynet.be Thu Jul 18 14:49:16 2002 From: piet at skynet.be (Pieterjan d'Hertog) Date: Thu, 18 Jul 2002 14:49:16 +0200 Subject: [lir-wg] rfc-ignorant.org In-Reply-To: Message-ID: What about RFC954 dating from 1985... WHO SHOULD BE IN THE DATABASE DCA requests that each individual with a directory on an ARPANET or MILNET host, who is capable of passing traffic across the DoD Internet, be registered in the NIC WHOIS Database. MILNET TAC users must be registered in the database. To register, send via electronic mail to REGISTRAR at SRI-NIC.ARPA your full name, middle initial, U.S. mailing address (including mail stop and full explanation of abbreviations and acronyms), ZIP code, telephone (including Autovon and FTS, if available), and one network mailbox. Contact the DDN Network Information Center, REGISTRAR at SRI-NIC.ARPA or (800) 235-3155, for assistance with registration. Shouldn't it be made obsolete ? From he at uninett.no Thu Jul 18 16:03:47 2002 From: he at uninett.no (Havard Eidnes) Date: Thu, 18 Jul 2002 16:03:47 +0200 (CEST) Subject: [lir-wg] rfc-ignorant.org In-Reply-To: References: Message-ID: <20020718.160347.69062003.he@uninett.no> > What about RFC954 dating from 1985... > > > WHO SHOULD BE IN THE DATABASE > > DCA requests that each individual with a directory on an ARPANET or > MILNET host, who is capable of passing traffic across the DoD > Internet, be registered in the NIC WHOIS Database. MILNET TAC users > must be registered in the database. To register, send via electronic > mail to REGISTRAR at SRI-NIC.ARPA your full name, middle initial, U.S. > mailing address (including mail stop and full explanation of > abbreviations and acronyms), ZIP code, telephone (including Autovon > and FTS, if available), and one network mailbox. Contact the DDN > Network Information Center, REGISTRAR at SRI-NIC.ARPA or (800) 235-3155, > for assistance with registration. > > > Shouldn't it be made obsolete? Well, formally, the document's status is as follows: 0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Status: DRAFT STANDARD) In other words, it defines the simple WHOIS protocol. However, as is not uncommon for RFC documents produced in those days, the document mixes operational requirements and procedures with actual protocol specification, thus the above quoted paragraph. I'm however not aware of any attempt at re-specifying the WHOIS protocol itself, so that the above document can be moved to historic status; if you want to play along those lines, "feel free". However, I'm not sure a re-specification of the WHOIS protocol is going to quiet the rfc-ignorant.org folks' on this point. The question appears to be: "must there be registered at least one e-mail address per assigned address block", be that in either ARIN, RIPE or APNICs whois databases. Regards, - H?vard From krazavi at dpimail.net Thu Jul 18 16:23:26 2002 From: krazavi at dpimail.net (Razavi (Support)) Date: Thu, 18 Jul 2002 18:53:26 +0430 Subject: [lir-wg] RE: Help Again Please ! In-Reply-To: <20020718123021.GB6642@nic.fr> Message-ID: I know about this site and i have some documents, but the problem is they dont help and dont give enough information, even i have training course booklet but its not clear ! Regards, --Cathy Razavi. -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer at gitoyen.net] Sent: Thursday, July 18, 2002 5:00 PM To: Razavi (Support) Cc: bortzmeyer at gitoyen.net Subject: Re: Help Again Please ! On Mon, Jul 15, 2002 at 03:20:50PM +0430, Razavi (Support) wrote a message of 9 lines which said: > How can i change our Database or how can i have access to our DB ? i want > to change the information about technical person and get a new Nichhandle ! Read RIPE's documentation. www.ripe.net, it is well organized. From john at apnic.net Fri Jul 19 02:00:23 2002 From: john at apnic.net (John Tran) Date: Fri, 19 Jul 2002 10:00:23 +1000 (EST) Subject: [hostmaster-staff] Re: [lir-wg] rfc-ignorant.org In-Reply-To: <20020718.160347.69062003.he@uninett.no> Message-ID: On Thu, 18 Jul 2002, Havard Eidnes wrote: > > What about RFC954 dating from 1985... > > > > > > WHO SHOULD BE IN THE DATABASE > > > > DCA requests that each individual with a directory on an ARPANET or > > MILNET host, who is capable of passing traffic across the DoD > > Internet, be registered in the NIC WHOIS Database. MILNET TAC users > > must be registered in the database. To register, send via electronic > > mail to REGISTRAR at SRI-NIC.ARPA your full name, middle initial, U.S. > > mailing address (including mail stop and full explanation of > > abbreviations and acronyms), ZIP code, telephone (including Autovon > > and FTS, if available), and one network mailbox. Contact the DDN > > Network Information Center, REGISTRAR at SRI-NIC.ARPA or (800) 235-3155, > > for assistance with registration. > > > > > > Shouldn't it be made obsolete? > > Well, formally, the document's status is as follows: > > 0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. > Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Status: > DRAFT STANDARD) > > In other words, it defines the simple WHOIS protocol. However, as is > not uncommon for RFC documents produced in those days, the document > mixes operational requirements and procedures with actual protocol > specification, thus the above quoted paragraph. > > I'm however not aware of any attempt at re-specifying the WHOIS protocol > itself, so that the above document can be moved to historic status; if > you want to play along those lines, "feel free". > > However, I'm not sure a re-specification of the WHOIS protocol is going > to quiet the rfc-ignorant.org folks' on this point. > > > The question appears to be: "must there be registered at least one > e-mail address per assigned address block", be that in either ARIN, RIPE > or APNICs whois databases. FYI, For the person object in APNIC database. e-mail: [mandatory] [multiple] [look-up key] Even with making email mandatory we still having problem with email address being out of date due to people forget to update the database with changes. Son > > > Regards, > > - H?vard > * Mailing List: hostmaster-staff * > * Handled by majordomo at staff.apnic.net * > From he at uninett.no Fri Jul 19 10:22:06 2002 From: he at uninett.no (Havard Eidnes) Date: Fri, 19 Jul 2002 10:22:06 +0200 (CEST) Subject: [lir-wg] rfc-ignorant.org In-Reply-To: References: <20020718.160347.69062003.he@uninett.no> Message-ID: <20020719.102206.41789698.he@uninett.no> > FYI, For the person object in APNIC database. > > e-mail: [mandatory] [multiple] [look-up key] > > Even with making email mandatory we still having problem with email > address being out of date due to people forget to update the > database with changes. Oh, yes, I have no illusions about whether this will actually be a universal solution to any problem other than as a means to get the rfc-ignorant.org folks off our collective backs. People unwilling to provide a usable e-mail address will just fill in a non-usable (/dev/null'ed?) e-mail address. Regards, - H?vard From woeber at cc.univie.ac.at Fri Jul 19 11:13:36 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 19 Jul 2002 11:13:36 +0200 Subject: [lir-wg] rfc-ignorant.org Message-ID: <00A1129D.CAA2659A.9@cc.univie.ac.at> >Oh, yes, I have no illusions about whether this will actually be a >universal solution to any problem other than as a means to get the >rfc-ignorant.org folks off our collective backs. People unwilling to >provide a usable e-mail address will just fill in a non-usable >(/dev/null'ed?) e-mail address. It's not going to get anybody anywhere, unless we go to the extreme of a 3-way verification as a precondition to holdership of resources registered in the DB, and a recurring verification procedure. If you force a "usable address" you might as well end up with an anon mailer at yahoo, hotmail, gmx,... And if you block those, then nobody prevents me from simply picking an address which is contained in a different, randomly chosen, object. Pretty cheap DoS mechanism, in the end ;-) And last but not least, with the procedures in place for many (most?) ISPs these days, and the channnel-hopping behaviour of users/sites in the domain name space, there is no basis any longer for consistency *and actually getting a human being look at the message*. If rfc-ignorant.org folks don't understand that, then we should suggest a default entry being put in by the DB software (how about postmaster at rfc-ignorant.org ?). A maybe more heplful question would be: what do they want to achieve, and is there reasonable merit in those goals to have the community find a sound mechanism for implementation? Wilfried. From ncc at ripe.net Fri Jul 19 16:53:20 2002 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 19 Jul 2002 16:53:20 +0200 Subject: [lir-wg] New address announcement Message-ID: <200207191453.g6JErKt21656@birch.ripe.net> Dear Colleagues, The RIPE NCC has a new postal address. The new address is: RIPE NCC P.O. Box 10096 1001 EB AMSTERDAM THE NETHERLANDS The new address should be used for all postal contacts. Please update your records to reflect this change. Kind Regards, The RIPE NCC From bruce.campbell at ripe.net Thu Jul 18 18:10:16 2002 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Thu, 18 Jul 2002 18:10:16 +0200 (CEST) Subject: [lir-wg] rfc-ignorant.org In-Reply-To: <20020718.160347.69062003.he@uninett.no> Message-ID: On Thu, 18 Jul 2002, Havard Eidnes wrote in reply to Pieterjan d'Hertog: > > What about RFC954 dating from 1985... > > > > > > WHO SHOULD BE IN THE DATABASE > > > > DCA requests that each individual with a directory on an ARPANET or > > MILNET host, who is capable of passing traffic across the DoD > > > > > > Shouldn't it be made obsolete? > > I'm however not aware of any attempt at re-specifying the WHOIS protocol > itself, so that the above document can be moved to historic status; if > you want to play along those lines, "feel free". Actually, there is: ftp://ftp.isi.edu/in-notes/search.ietf.org/internet-drafts/draft-campbell-whois-00.txt I've attempted to define the WHOIS (actually 'nicname') protocol to be independent of any expectations of output formats or what is in the database, and keep it to a simple question/answer protocol with a few basic niceties (such as 'help'). Another draft was put forward on the ietf-whois list some time ago which explicitly shifted 954 to Historic, although I cannot find this as an internet draft at the present time. > However, I'm not sure a re-specification of the WHOIS protocol is going > to quiet the rfc-ignorant.org folks' on this point. On this matter, it will, however they will find other aspects to complain about. > The question appears to be: "must there be registered at least one > e-mail address per assigned address block", be that in either ARIN, RIPE > or APNICs whois databases. In the original mail to lir-wg, the range in question meets this criteria (the tech-c has an email address, the adminc-c does not), hence rfci's listing is incorrect by their own cited policy ;) -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security From ncc at ripe.net Fri Jul 19 08:34:19 2002 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Fri, 19 Jul 2002 08:34:19 +0200 Subject: [lir-wg] New Document available: RIPE-254 Message-ID: <200207190634.g6J6YJt03417@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. "IRT Object in the RIPE Database" (ripe-254) Short content description ------------------------- This document describes the irt object and related functionality in the RIPE Database. The irt object is used to provide information about a Computer Security Incident Response Team (CSIRT). This document also describes the creation procedure for the irt object. Accessing the RIPE document store --------------------------------- The document is on-line at the following URL: http://www.ripe.net/ripe/docs/irt-object.html The RIPE document store is 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-254.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-254.txt plain text version Kind Regards, RIPE NCC Document Announcement Service From andrei at ripe.net Tue Jul 23 09:36:38 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 23 Jul 2002 09:36:38 +0200 Subject: [lir-wg] Re: Draft document "New Values of the 'status:' attribute for inet6num Objects" is available References: <3D358A3B.6060205@ripe.net> <3D39E4A8.BBE0A946@renater.fr> Message-ID: <3D3D0786.7000205@ripe.net> Dear Bernard, Bernard Tuy wrote: > ====BT: Hi Andrei, > > I've not seen that much comments on the ripe-lists ... did you get some personally ? > if it is the case, could you give a summary of them ? > There was some discussion on the lir-wg mailing list and the summary was presented by Leo Vegoda (http://www.ripe.net/ripe/mail-archives/lir-wg/20020701-20021001/msg00002.html) > In anycase, couldn't we wait until the Rodhos meeting to present the final version of > this > document ? > The main problem with delaying the deployment of the proposed functionality is that registrations with incorrect status value are entered into the database. What makes you uncomfortable with the proposed draft? Please feel free to propose changes to the document so we can move forward. > Cheers, > > +Bernard T. > --- Regards, Andrei > > Andrei Robachevsky wrote: > >>Dear Colleagues, >> >>[apologies for duplicate messages] >> >>The draft document "New Values of the 'status:' attribute for inet6num >>Objects" is available on the RIPE NCC website at: >> >>http://www.ripe.net/ripencc/draft-documents/ >> >>This document describes the new values of the "status:" attribute for >>inet6num objects and their impact on database operation. >> >>The deadline for comments and suggestions is Wednesday, 24th July. After >>incorporating any suggested changes to the document the final document >>will be published as a RIPE Document. On Thursday, 25th July, subject to >>any additional comments, the described Database functionality will be >>put in to practice. >> >>Please send your comments and suggestions to . >> >>Regards, >> >>Andrei Robachevsky >>RIPE NCC > -- Andrei From bernard.tuy at renater.fr Sun Jul 21 00:31:04 2002 From: bernard.tuy at renater.fr (Bernard Tuy) Date: Sun, 21 Jul 2002 00:31:04 +0200 Subject: [lir-wg] Re: Draft document "New Values of the 'status:' attribute for inet6num Objects" is available References: <3D358A3B.6060205@ripe.net> Message-ID: <3D39E4A8.BBE0A946@renater.fr> ====BT: Hi Andrei, I've not seen that much comments on the ripe-lists ... did you get some personally ? if it is the case, could you give a summary of them ? In anycase, couldn't we wait until the Rodhos meeting to present the final version of this document ? Cheers, +Bernard T. --- Andrei Robachevsky wrote: > > Dear Colleagues, > > [apologies for duplicate messages] > > The draft document "New Values of the 'status:' attribute for inet6num > Objects" is available on the RIPE NCC website at: > > http://www.ripe.net/ripencc/draft-documents/ > > This document describes the new values of the "status:" attribute for > inet6num objects and their impact on database operation. > > The deadline for comments and suggestions is Wednesday, 24th July. After > incorporating any suggested changes to the document the final document > will be published as a RIPE Document. On Thursday, 25th July, subject to > any additional comments, the described Database functionality will be > put in to practice. > > Please send your comments and suggestions to . > > Regards, > > Andrei Robachevsky > RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2477 bytes Desc: S/MIME Cryptographic Signature URL: From ripe-dbm at ripe.net Tue Jul 23 11:07:34 2002 From: ripe-dbm at ripe.net (RIPE Database Manager) Date: Tue, 23 Jul 2002 11:07:34 +0200 Subject: [lir-wg] Re: NCC#2002069654 NCC#2002069654 HMQUESTION In-Reply-To: <001f01c22ca7$5df8c420$7bcb87d4@walrus>; from Knowtion Hostmaster Role Account on Tue, 16 Jul 2002 10:00:03 +0100 References: <200206170937.g5H9bHA28671@birch.ripe.net> <200207041524.g64FOpH20331@cow.ripe.net> <01ab01c22376$23ed1bd0$2728a8c0@carpenter> <200207111513.g6BFDNP25937@cow.ripe.net> <000401c228f4$78028ec0$78cb87d4@walrus> <200207160801.g6G81pb12469@cow.ripe.net> <001f01c22ca7$5df8c420$7bcb87d4@walrus> Message-ID: <200207230907.g6N97Y423818@x41.ripe.net> Dear Peter, The maintainer AS9179-MNT maintains quite a lot of objects in the database. Do you want it removed from all of these or just some of them? Can you let us know which objects you no longer wish to be associated with. Regards Denis Walker RIPE NCC Database Administration On Tue, 16 Jul 2002 10:00:03 +0100, Knowtion Hostmaster Role Account wrote: * > You could consider contacting the relevant contacts related to the objects * > in question. They may have their own maintainer they want to place on the * > objects, in which case you could send an update with the new maintainer as * the * > mnt-by: attribute. * * They do not respond. Let us assume that the actual contacts are either * 'stupid' or 'hostile'. What then ? * * Peter * * > If need be the following URL provides information on the creation of a new * > maintainer: * > * > * > * http://www.ripe.net/ripencc/pub-services/db/Maintainer_Creation_Procedure.ht * ml * > * > Please contact me if you require further assistance. * > * > * > Kind regards, * > * > Winston Schenkers * > RIPE NCC * > * > On Thu, 11 Jul 2002 17:03:16 +0100, Knowtion Hostmaster Role Account * wrote: * > * > You are correct to say that you can not remove a maintainer from a * > * * > * > object without adding a new one. * > * > * > * > The attribute in the object is mandatory, the AS * number * > * > AS9179 is part of the from the RIPE NCC, and if correct the * > * > maintainer is being maintained by yourselves. * > * * > * How can I phrase this better ? * > * * > * AS9179-MNT (me / my company) is the current but out-of-date maintainer * on an * > * object. Without deleting the object (as it is not relly mine) how can I * > * cease being associated with it ? * > * * > * I (AS9179-MNT) no longer am the maintainer of various objects that * really * > * belong to the company X in the UK. My company has not been associated * with * > * them or provided services to them for sometime. * > * * > * Is it good and recommended practice therefore for me to just delete the * > * objects - this may affect someones service ? * > * * > * cc'ed to lir-wg in case anyone has a better idea... * > * * > * Petr * > * * > * From peter.galbavy at knowtion.net Tue Jul 23 11:42:06 2002 From: peter.galbavy at knowtion.net (Peter Galbavy) Date: Tue, 23 Jul 2002 10:42:06 +0100 Subject: [lir-wg] Re: NCC#2002069654 NCC#2002069654 HMQUESTION References: <200206170937.g5H9bHA28671@birch.ripe.net> <200207041524.g64FOpH20331@cow.ripe.net> <01ab01c22376$23ed1bd0$2728a8c0@carpenter> <200207111513.g6BFDNP25937@cow.ripe.net> <000401c228f4$78028ec0$78cb87d4@walrus> <200207160801.g6G81pb12469@cow.ripe.net> <001f01c22ca7$5df8c420$7bcb87d4@walrus> <200207230907.g6N97Y423818@x41.ripe.net> Message-ID: <00bf01c2322d$37a088e0$2728a8c0@carpenter> No! Please leave everything for the moment... My question was a general one. Once I have the answer - which seems to be the one below - then I will forward requests to be removed as separate requests to hostmaster at ripe.net. It is that simply this situation is not covered in existing RIPE documents - or at least that I have read. Peter ----- Original Message ----- From: "RIPE Database Manager" To: "Knowtion Hostmaster Role Account" Cc: ; "RIPE NCC" Sent: Tuesday, July 23, 2002 10:07 AM Subject: [lir-wg] Re: NCC#2002069654 NCC#2002069654 HMQUESTION > Dear Peter, > > The maintainer AS9179-MNT maintains quite a lot of objects in the database. > Do you want it removed from all of these or just some of them? Can you let > us know which objects you no longer wish to be associated with. > > Regards > Denis Walker > RIPE NCC Database Administration > > > On Tue, 16 Jul 2002 10:00:03 +0100, Knowtion Hostmaster Role Account wrote: > * > You could consider contacting the relevant contacts related to the objects > * > in question. They may have their own maintainer they want to place on the > * > objects, in which case you could send an update with the new maintainer as > * the > * > mnt-by: attribute. > * > * They do not respond. Let us assume that the actual contacts are either > * 'stupid' or 'hostile'. What then ? > * > * Peter > * > * > If need be the following URL provides information on the creation of a new > * > maintainer: > * > > * > > * > > * http://www.ripe.net/ripencc/pub-services/db/Maintainer_Creation_Procedure.ht > * ml > * > > * > Please contact me if you require further assistance. > * > > * > > * > Kind regards, > * > > * > Winston Schenkers > * > RIPE NCC > * > > * > On Thu, 11 Jul 2002 17:03:16 +0100, Knowtion Hostmaster Role Account > * wrote: > * > * > You are correct to say that you can not remove a maintainer from a > * > * > * > * > object without adding a new one. > * > * > > * > * > The attribute in the object is mandatory, the AS > * number > * > * > AS9179 is part of the from the RIPE NCC, and if correct the > * > * > maintainer is being maintained by yourselves. > * > * > * > * How can I phrase this better ? > * > * > * > * AS9179-MNT (me / my company) is the current but out-of-date maintainer > * on an > * > * object. Without deleting the object (as it is not relly mine) how can I > * > * cease being associated with it ? > * > * > * > * I (AS9179-MNT) no longer am the maintainer of various objects that > * really > * > * belong to the company X in the UK. My company has not been associated > * with > * > * them or provided services to them for sometime. > * > * > * > * Is it good and recommended practice therefore for me to just delete the > * > * objects - this may affect someones service ? > * > * > * > * cc'ed to lir-wg in case anyone has a better idea... > * > * > * > * Petr > * > * > * > > * > From bortzmeyer at gitoyen.net Tue Jul 23 12:29:34 2002 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Tue, 23 Jul 2002 12:29:34 +0200 Subject: [lir-wg] Re: Help Again Please ! In-Reply-To: References: <20020718123021.GB6642@nic.fr> Message-ID: <20020723102934.GA26500@nic.fr> On Thu, Jul 18, 2002 at 06:53:26PM +0430, Razavi (Support) wrote a message of 24 lines which said: > I know about this site and i have some documents, but the problem is they > dont help and dont give enough information, even i have training course > booklet but its not clear ! Either you are a LIR of RIPE or you are not. If you are, you have no choice but reading the documentation (and may be attending the courses). If you are not, which I suspect, ask to the LIR (the Internet provider you use). What is the object handle in the RIPE database? From mohamed_iah at link.net Wed Jul 24 20:10:42 2002 From: mohamed_iah at link.net (Mohamed Ibrahem) Date: Wed, 24 Jul 2002 20:10:42 +0200 Subject: [lir-wg] join two objects Message-ID: Dear all I have some objects for the same customer and I want to merge them in one object. Please advise THANX Mohamed Ibrahim Ali Data Communication ENG From Janko.Thoss at envia-tel.de Thu Jul 25 08:07:52 2002 From: Janko.Thoss at envia-tel.de (=?iso-8859-1?Q?=22Tho=DF=2C_Janko=22?=) Date: Thu, 25 Jul 2002 08:07:52 +0200 Subject: [lir-wg] Question to a multihomed PA-space connection Message-ID: Hello, I have "little" question (but notice that I'm not a guru in BGP-routing and RIPE-problems). We want to connect a customer which don't want to register as a new AS. But he wants a connect to 2 provivers (different AS's). We have tried to get PI-space from RIPE but the automaticly response told us the following: -------- Quote -------- 1. Why is PI space required rather than PA space? - If PI is requested for multi-homing please explain why the second provider cannot route PA space as a more specific route(with the PA block holder adding a more specific route too). - The same policies apply to PI space as PA. Administrative ease and/or routing are not reasons for PI. Please read the information about PA/PI from the RIPE Document, IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region, Sections 5.1.5 and 5.1.6: -------- Unquote -------- Can anyone tell me what is to do for that the second provider is able to announce the /24-PA from the first provider (to emulate a multihomed connection) or is it only possible to use the second provider for backup with the same space? wait hopefully for tips or hints regards, Janko Tho? -- envia.tel GmbH Projektmanager Leipziger Str. 116 b 04425 Taucha Tel.: +49 (0) 341 / 120 7069 Fax: +49 (0) 341 / 120 7052 Mobil: +49 (0) 173 / 379 0048 eMail: janko.thoss at envia-tel.de Web: http://www.envia-tel.de From pbenjes at gblx.net Thu Jul 25 08:29:24 2002 From: pbenjes at gblx.net (Paul Benjes) Date: Wed, 24 Jul 2002 23:29:24 -0700 (MST) Subject: [api-ip] [lir-wg] Question to a multihomed PA-space connection In-Reply-To: Message-ID: equal policy routing, no AS required; here's an example of the commands; 8 - I have two providers and two separate ip netblocks .. yours and the other guys.. How do I route machines using your ip's down your interface, and machines using the other guys ip's down his interface? simple need three things a way to determine which machine is talking.. -- access list based on this source address change the default route on the fly --- route maps and apply the above solution to the interfaces. -- interface cmds below ! these match the blocks you got from different providers ! notice the ip NETWORK-ADDRESS and inverted MASK (the any is the destination) access-list 198 permit ip 208.48.145.0 0.0.0.255 any access-list 199 permit ip 207.67.174.128 0.0.0.63 any ! these set the policy and the default route on the fly ! these set only the default address if the block is not directly connected route-map equal-access permit 10 match ip address 198 set ip default next-hop 204.246.203.113 ^^^^^^^^^^^^^^^ far side of 198 block route-map equal-access permit 20 match ip address 199 set ip default next-hop 204.137.203.153 ^^^^^^^^^^^^^^^ far side of 199 block ! these apply the above to the interfaces ! this example applies to two separate interfaces ! individually configured .. if both ip addresses are on the same ! interface using the secondary command.. just apply to that interface interface E0 ip policy route-map equal-access ! int e1 ip policy route-map equal-access On Thu, 25 Jul 2002, [iso-8859-1] "Tho?, Janko" wrote: > Hello, > > I have "little" question (but notice that I'm not a guru in BGP-routing and > RIPE-problems). > We want to connect a customer which don't want to register as a new AS. But > he wants a connect to 2 provivers (different AS's). > We have tried to get PI-space from RIPE but the automaticly response told us > the following: > -------- Quote -------- > 1. Why is PI space required rather than PA space? > > - If PI is requested for multi-homing please explain why the > second provider cannot route PA space as a more specific > route(with the PA block holder adding a more specific route > too). > > - The same policies apply to PI space as PA. Administrative ease > and/or routing are not reasons for PI. Please read the information > about PA/PI from the RIPE Document, IPv4 Address Allocation and > Assignment Policies in the RIPE NCC Service Region, Sections 5.1.5 > and 5.1.6: > -------- Unquote -------- > > Can anyone tell me what is to do for that the second provider is able to > announce the /24-PA from the first provider (to emulate a multihomed > connection) or is it only possible to use the second provider for backup > with the same space? > > wait hopefully for tips or hints > > regards, > Janko Tho? > > -- > envia.tel GmbH > Projektmanager > Leipziger Str. 116 b > 04425 Taucha > > Tel.: +49 (0) 341 / 120 7069 > Fax: +49 (0) 341 / 120 7052 > Mobil: +49 (0) 173 / 379 0048 > eMail: janko.thoss at envia-tel.de > Web: http://www.envia-tel.de > --------------------------------------------- Paul J. Benjes, CCNP Director of IP Engineering - API GlobalCrossing, Inc pbenjes at gblx.net 602.357.6454 Desk 602.357.6493 FAX "Do or do not, there is no try." - Yoda FingerPrint: F5BD 6754 7CFD 9859 3A40 05C0 40DB 4A68 6749 3030 PGP KEY ID: 0x67493030 --------------------------------------------- From andrei at ripe.net Thu Jul 25 17:22:26 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 25 Jul 2002 17:22:26 +0200 Subject: [lir-wg] Mntners with only MAIL-FROM auth Message-ID: <3D4017B2.8000702@ripe.net> Attention owners of mntner objects using _only_ MAIL-FROM authentication method. Dear Colleagues, We recently sent out a message to all contacts for maintainers that still used MAIL-FROM as the ONLY means of authentication. This method is no longer valid and no updates can be authorised if any of the maintainers checked are in this situation. The message pointed to the proposed procedure on how to fix such situation (http://www.ripe.net/db/mailfrom.html). The RIPE-DBM support team has been overwhelmed with fax requests to update these maintainers. At the moment we are not able to respond to these requests as quickly as we would like to do. We have found it necessary to give a higher priority to other support requests. Therefore the response time for updates to maintainer authentication may be 5 to 10 working days. Please do not send repeat faxes unless we ask for them and do not send e-mails asking for a status update on the changes. This only slows the whole process down. We will reply to each request as soon as we make the change or find that we need additional information. This message will also be sent to all contacts for maintainers that still use MAIL-FROM as the ONLY means of authentication. Please bear with us on this and we apologise for the delay. Regards, Andrei Robachevsky DB Group Manager RIPE NCC From leo at ripe.net Thu Jul 25 17:27:55 2002 From: leo at ripe.net (leo vegoda) Date: Thu, 25 Jul 2002 17:27:55 +0200 Subject: [lir-wg] New draft: "New Values of the 'status:' attribute for inet6num Objects" Message-ID: <20020725152755.GA17751@ripe.net> Dear Colleagues, Thank you for the comments we have received on the draft document "New Values of the 'status:' attribute for inet6num Objects". We have revised it to incorporate the suggestions you have made. The meaning of the labels has been made clearer, in line with the comments received. ALLOCATED-BY-RIR - For allocations made by an RIR to an LIR. ALLOCATED-BY-LIR - For allocations made by an LIR or an LIR's downstream customer to another downstream organisation. ASSIGNED - For assignments made to End User sites The new draft is available from our web site at: We would welcome comments on this new draft until Thursday, 1 August 2002. All comments and suggestions should be sent to . Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From woeber at cc.univie.ac.at Fri Jul 26 11:39:44 2002 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 26 Jul 2002 11:39:44 +0200 Subject: [lir-wg] Re: New draft: "New Values of the 'status:' attribute for inet6num Objects" Message-ID: <00A11821.99DFEA2A.3@cc.univie.ac.at> Dear Leo and "Team", >The new draft is available from our web site at: > > Looks good! >We would welcome comments on this new draft until Thursday, 1 August >2002. All comments and suggestions should be sent to . Procedural question: How are we going to modify existing objects to conform to this proposal? Right now the template query returns: bash-2.05a$ wripe -t inet6num [ ... ] inet6num: [mandatory] [single] [primary/look-up key] [ ... ] status: [generated] [single] [ ] [ ... ] and it seems to be "optional" for the (new) ALLOCATED-BY-RIR case: bash-2.05a$ wripe -r 2001:0628::/35 [ ... ] inet6num: 2001:0628::/35 netname: AT-ACONET-19990920 descr: ACOnet Sub-TLA block country: AT admin-c: WW144 tech-c: WW144 tech-c: WK42 tech-c: CP8-RIPE notify: Domain-Admin at UniVie.ac.at mnt-by: RIPE-NCC-HM-MNT mnt-lower: ACONET-LIR-MNT changed: hostmaster at ripe.net 19990920 changed: hostmaster at ripe.net 20011019 source: RIPE Is this going to change? E.g. to: status: [mandatory] [single] [ ] The wording used in the draft seems to indicate [optional] [single] [ ]. I think some clarification would be helpful. Thanks, cheers, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From leo at ripe.net Fri Jul 26 16:00:19 2002 From: leo at ripe.net (leo vegoda) Date: Fri, 26 Jul 2002 16:00:19 +0200 Subject: [lir-wg] Re: New draft: "New Values of the 'status:' attribute for inet6num Objects" In-Reply-To: <00A11821.99DFEA2A.3@cc.univie.ac.at> References: <00A11821.99DFEA2A.3@cc.univie.ac.at> Message-ID: <20020726140018.GA20718@ripe.net> Hi Wilfried, On Fri, Jul 26, 2002 at 11:39:44AM +0200, Wilfried Woeber, UniVie/ACOnet wrote: Re: Re: New draft: "New Values of the 'status:' attribute for inet6num Objects" [...] > How are we going to modify existing objects to conform to this proposal? > Right now the template query returns: > > bash-2.05a$ wripe -t inet6num > [ ... ] > inet6num: [mandatory] [single] [primary/look-up key] > [ ... ] > status: [generated] [single] [ ] > [ ... ] > > and it seems to be "optional" for the (new) ALLOCATED-BY-RIR case: [...] > Is this going to change? E.g. to: > > status: [mandatory] [single] [ ] > > The wording used in the draft seems to indicate [optional] [single] [ ]. > I think some clarification would be helpful. The status attribute will be mandatory. The template and verbose information on whois.ripe.net will be updated to make this clear. The RIPE NCC will use ASSIGNED status inet6nums to determine the HD ratio of an allocation when a request is made for an additional allocation. We intend to update all inet6num objects maintianed by our maintainer on the day the new functionality is implemented. Best regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager From Robert.Kiessling at de.easynet.net Fri Jul 26 16:47:02 2002 From: Robert.Kiessling at de.easynet.net (Robert Kiessling) Date: 26 Jul 2002 15:47:02 +0100 Subject: [lir-wg] Re: New draft: "New Values of the 'status:' attribute for inet6num Objects" In-Reply-To: <20020726140018.GA20718@ripe.net> References: <00A11821.99DFEA2A.3@cc.univie.ac.at> <20020726140018.GA20718@ripe.net> Message-ID: leo vegoda writes: > We intend to update all inet6num objects maintianed by our > maintainer on the day the new functionality is implemented. I would suggest to update all objects: - /32 and /35 with "status: SUBTLA" to ALLOCATED-BY-RIR - /48 to ASSIGNED - everything else to ALLOCATED-BY-LIR This way there's a consistent state any we don't need to deal with legacy attribute values. This would also ensure that all objects have a status attribute, thus eliminating the exception (no status attribute) which occured during database software migration. Robert From c.christophorou at cytanet.com.cy Tue Jul 30 08:04:10 2002 From: c.christophorou at cytanet.com.cy (Christakis Christophorou) Date: Tue, 30 Jul 2002 08:04:10 +0200 Subject: [lir-wg] PGP support Message-ID: <018001c2378e$ef2f3f90$012b010a@cyta> Dear colleagues, I would like to implement a PGP authentication scheme with RIPE. I would appreciate any help including suggestions about any plugin to be used with an existing email client software (outlook express etc) or any completely independent software. I have tried PGP Freeware with success but keys state that this version is for "non commercial use" and Network Associates does not support it any more. I have also tried GnuPG but without any success (keys are created with 0 bytes). Thanks Chris From leo at ripe.net Wed Jul 31 17:51:38 2002 From: leo at ripe.net (leo vegoda) Date: Wed, 31 Jul 2002 17:51:38 +0200 Subject: [lir-wg] AS Number Policy - continued Message-ID: <20020731155138.GA3592@ripe.net> Dear Colleagues, Thank you for your comments on my initial questions and the wide ranging discussion that took place. I would like to continue this discussion by asking two more questions: 1. Should the RIPE NCC check whether Autonomous System Numbers it has assigned become multi-homed within six months? If you would like us to do this, the RIPE NCC proposes to do so by looking at routing policies registered in the Routing Registry. 2. Should the policy be changed so that AS numbers not in use can be reclaimed? If there is consensus on this we propose to reclaim AS numbers of networks not multi-homed after six months. Kind regards, -- leo vegoda RIPE NCC Registration Services From s.willing at mops.net Wed Jul 31 17:59:46 2002 From: s.willing at mops.net (Sebastian Willing) Date: Wed, 31 Jul 2002 17:59:46 +0200 (CEST) Subject: [lir-wg] AS Number Policy - continued In-Reply-To: <20020731155138.GA3592@ripe.net> from "leo vegoda" at Jul 31, 2002 05:51:38 PM Message-ID: <200208010803.KAA06861@mara.mops.net> Hello! leo vegoda wrote: > > Dear Colleagues, > > Thank you for your comments on my initial questions and the > wide ranging discussion that took place. > > I would like to continue this discussion by asking two more > questions: > > 1. Should the RIPE NCC check whether Autonomous System Numbers > it has assigned become multi-homed within six months? If you > would like us to do this, the RIPE NCC proposes to do so by > looking at routing policies registered in the Routing Registry. As everyone is required to keep their whois-db-objects up to date, this should be the first source to be checked. The data could be verified from the RIPE's BGP router(s) and from public looking glasses (which may be used automatically). > > 2. Should the policy be changed so that AS numbers not in use > can be reclaimed? If there is consensus on this we propose > to reclaim AS numbers of networks not multi-homed after six > months. I'ld say: Reclaim after six month, but always consider the reasons, which may be told by the LIR (for not being multihomed). Just my 2 ct. Sebastian -- ************************************************************************ mopSys GmbH Sebastian Willing http://www.mops.net Technical director Telefon: 05139/9813-11 e-Mail: s.willing at mops.net Telefax: 05139/9813-13 Webspace ab 2,5 EUR: http://www.ciz.de/ ************************************************************************