% Note: this output has been filtered. % To receive output for a database update, use the "-B" flag.
% Information related to 'AS3209 - AS3353'
as-block: AS3209 - AS3353 descr: RIPE NCC ASN block remarks: These AS Numbers are assigned to network operators in the RIPE NCC service region. mnt-by: RIPE-NCC-HM-MNT created: 2010-05-11T11:44:28Z last-modified: 2014-02-24T13:15:16Z source: RIPE
% Information related to 'AS3320'
% Abuse contact for 'AS3320' is 'email@example.com'
aut-num: AS3320 as-name: DTAG org: ORG-DTA2-RIPE descr: Internet service provider operations remarks: peering coordinators for AS3320: remarks: abuse reports should be sent to the contacts listed in the registry entries for the IP address of the
offending host system
remarks: We share the view that for many networks (including ours:-) only some abstraction of the actual routing policy should/can
be published in the IRR.
Right now we are abstracting to a very essential minimum.
remarks: the most important and helpful use of the IRR is
to publish what a network will announce to peers and upstream
# we are providing that by means of the AS-set AS3320:AS-DTAG
# which we have been keeping up to date all the time remarks: we encourage all our neighbors to define and maintain an
AS-set to describe their announcements, and to register all the routes (and have their customers do so as well)
import: # heavy abstraction hits! well, we are ...
from AS-ANY # neither peering promiscuously
accept ANY # nor accepting all junk routes offered... remarks: we maintain a list of what our neighbors have told us
about their announcements towards AS3320 - in terms of
AS-set (preferred), AS number, route-set (and the IRR database used to publish)
remarks: in fact we apply route filters based on this for all neighbors - as far as feasible
remarks: for data published through the RIPE routing registry we generate filters automatically
remarks: we consider the integration of RIR and routing registry data
and the application of RPSS authorization a great feature
of the RIPE routing registry
# unfortunately this benefit is not available with any
# other IRR database that we know of...
# and some of the IRR databases allow essentially any garbage
# to be registered without any control - making those databases
# quite useless... export: to AS3320:AS-CUSTOMERS # but don't publish that list;
announce ANY # in general - if they ask for less, we can do export: to AS-ANY # for peers and others... announce AS3320:AS-DTAG
# for backwards compatibility the older AS-DTAG
# will be kept around for some more time -
# defined using just members: AS3320:AS-DTAG
# please convert to AS3320:AS-DTAG if you are still
# using the old AS-DTAG remarks: customers are strongly encouraged to define and maintain an AS-set that we will include in the definition
of AS3320:AS-DTAG (if we are told the name) remarks: this will be sufficient to have our peers accept the routes remarks: in any case peers - and any network in the Internet -
is free to apply some selective policy (e.g. prefix
# but we do not think that any such selective policy
# will be based on details of our routing policy omitted
# from this aut-num: object remarks: unfortunately some customers do not provide usable IRR data; we will NOT add to the uncontrolled garbage in the IRR by
proxy registering in some database that requires no
remarks: we advise customers that routes without IRR registration and not covered by AS3320:AS-DTAG may receive less than full support by some of our peer networks and other
parts of the Internet
remarks: ============================================================== IPv6 we do/publish essentially the same like for IPv4
mp-import: afi ipv6.unicast # heavy abstraction...
from AS-ANY # neither peering promiscuously
accept ANY # nor accepting all junk routes offered... mp-export: afi ipv6.unicast to AS3320:AS-CUSTOMERS-V6 # but don't publish that list;
announce ANY # in general - if they ask for less, we can do mp-export: afi ipv6.unicast
to AS-ANY # for peers and others... announce AS3320:AS-DTAG-V6 remarks: ============================================================== admin-c: RV32 tech-c: RV32 status: ASSIGNED mnt-by: RIPE-NCC-END-MNT tech-c: BP32-RIPE mnt-by: DTAG-RR created: 1970-01-01T00:00:00Z last-modified: 2017-11-15T09:13:45Z source: RIPE
organisation: ORG-DTA2-RIPE org-name: Deutsche Telekom AG org-type: LIR address: Eduard-Schopf-Allee 1 address: D-28217 address: Bremen address: GERMANY phone: +491607069891 fax-no: +494412344589 admin-c: DTAG-RIPE admin-c: MR22061-RIPE admin-c: UR661-RIPE admin-c: SL7866-RIPE admin-c: VZ56-RIPE admin-c: SP8519-RIPE admin-c: REIS1-RIPE admin-c: HI56-RIPE admin-c: PB4856-RIPE admin-c: MBT1-RIPE admin-c: BP32-RIPE admin-c: LB470-RIPE admin-c: ES4155-RIPE admin-c: RV32 admin-c: PA3357-RIPE admin-c: SB15220-RIPE admin-c: KUNO2-RIPE admin-c: HB3076-RIPE admin-c: LF1459-RIPE admin-c: KB6787-RIPE abuse-c: DTAG3-RIPE mnt-ref: RIPE-NCC-HM-MNT mnt-ref: DTAG-NIC mnt-by: RIPE-NCC-HM-MNT mnt-by: DTAG-NIC created: 2004-04-17T11:12:44Z last-modified: 2018-05-08T12:28:26Z source: RIPE # Filtered
person: Berthold Paffrath address: Deutsche Telekom AG, Internet Services address: Postfach 2767 address: D-48014 Muenster phone: +49 251 910 351 fax-no: +49 251 910 399 nic-hdl: BP32-RIPE mnt-by: DTAG-RR created: 1970-01-01T00:00:00Z last-modified: 2001-09-21T23:34:28Z source: RIPE # Filtered
person: Ruediger Volk address: Deutsche Telekom AG, Zentrum IOT address: Postfach 2767 address: D-48014 Muenster phone: +49 251 910 351 fax-no: +49 251 910 399 nic-hdl: RV32 mnt-by: DTAG-RR created: 1970-01-01T00:00:00Z last-modified: 2001-09-21T23:34:30Z source: RIPE # Filtered
% This query was served by the RIPE Database Query Service version 1.91.2 (ANGUS)