| SPAM | Blacklist
| Products/Services | GeneralInfo
| Definitions | Acronyms
Technical Support - Subject Areas
IP Addresses, Domain Names
CIDR (Classless Inter-Domain Routing)
IP Addresses, Domain Names
Classless Inter-Domain Routing (CIDR)
Where can I find a list of SBC DNS Servers and Resolvers for my service area?
The following is a list of SBC DNS servers and resolvers. DNS Servers, for hosting a zone file, should be selected
by region. DNS Resolvers should be selected by choosing the two cities closest to the customer location.
|The SBC Regional DNS servers are as follows: |
|Location ||Server Name ||IP Address ||Comments |
|SBC Southwest Region ||ns1.swbell.net ||22.214.171.124 ||Primary|
|SBC Southwest Region ||ns2.swbell.net ||126.96.36.199 ||Secondary|
|SBC West Region ||ns1.pbi.net ||188.8.131.52 ||Primary|
|SBC West Region ||ns2.pbi.net ||184.108.40.206 ||Secondary|
|SBC Midwest Region ||ns1.ameritech.net ||220.127.116.11 ||Primary|
|SBC Midwest Region ||ns2.ameritech.net ||18.104.22.168 ||Secondary|
|SBC SNET Region ||ns1.snet.net ||22.214.171.124 ||Primary |
|SBC SNET Region ||ns2.snet.net ||126.96.36.199 ||Secondary|
|The following DNS servers can be used in any SBC Region, however, ONLY Domain Names that
have been registered or transferred through the SBC E-Services, Inc. websites (http://webhosting.com) or
http://sbcdomreg.com) should reside on these servers.|
|Location ||Server Name ||IP Address ||Comments|
|SBC E-Services, Inc. ||ns1.sbcglobal.net ||188.8.131.52 ||Primary|
|SBC E-Services, Inc. ||ns2.sbcglobal.net ||184.108.40.206 ||Secondary
|The SBC Resolvers are as follows:|
|Location ||Resolver Name ||Primary Resolver IP ||Secondary Resolver IP|
|Arkansas ||dns1.fyvlar.sbcglobal.net (Fayetteville) ||220.127.116.11 ||18.104.22.168|
| ||dns1.ltrkar.sbcglobal.net (Little Rock) ||22.214.171.124 ||126.96.36.199|
|Kansas ||dns1.tpkaks.sbcglobal.net (Topeka) ||188.8.131.52 ||184.108.40.206|
| ||dns1.wchtks.sbcglobal.net (Wichita) ||220.127.116.11 ||18.104.22.168|
|Missouri ||dns1.ksc2mo.sbcglobal.net (Kansas City) ||22.214.171.124 ||126.96.36.199|
| ||dns1.spfdmo.sbcglobal.net (Springfield) ||188.8.131.52 ||184.108.40.206|
| ||dns1.stlsmo.sbcglobal.net (St. Louis) ||220.127.116.11 ||18.104.22.168|
|Oklahoma ||dns1.okcyok.sbcglobal.net (Oklahoma City) ||22.214.171.124 ||126.96.36.199|
| ||dns1.tulsok.sbcglobal.net (Tulsa) ||188.8.131.52 ||184.108.40.206|
|Texas ||dns1.ablntx.sbcglobal.net (Abilene) ||220.127.116.11 ||18.104.22.168|
| ||Amarillo ||22.214.171.124 ||126.96.36.199|
| ||dns1.austtx.sbcglobal.net (Austin) ||188.8.131.52 ||184.108.40.206|
| ||dns1.bumttx.sbcglobal.net (Beaumont) ||220.127.116.11 ||18.104.22.168|
| ||dns1.crchtx.sbcglobal.net (Corpus Christi) ||22.214.171.124 ||126.96.36.199|
| ||dns1.elpstx.sbcglobal.net (El Paso) ||188.8.131.52 ||184.108.40.206|
| ||Euless/Fort Worth ||220.127.116.11 ||18.104.22.168|
| ||Harlingen ||22.214.171.124 ||126.96.36.199|
| ||dns1.hstntx.sbcglobal.net (Houston) ||188.8.131.52 ||184.108.40.206|
| ||dns1.lgvwtx.sbcglobal.net (Longview) ||220.127.116.11 ||18.104.22.168|
| ||dns1.lbcktx.sbcglobal.net (Lubbock) ||22.214.171.124 ||126.96.36.199|
| ||McAllen ||188.8.131.52 ||184.108.40.206|
| ||dns1.mdldtx.sbcglobal.net (Midland) ||220.127.116.11 ||18.104.22.168|
| ||Odessa ||22.214.171.124 ||126.96.36.199|
| ||dns1.rcsntx.sbcglobal.net (Richardson) ||188.8.131.52 ||184.108.40.206|
| ||San Angelo ||220.127.116.11 ||18.104.22.168|
| ||dns1.snantx.sbcglobal.net (San Antonio) ||22.214.171.124 ||126.96.36.199|
| ||dns1.wacotx.sbcglobal.net (Waco) ||188.8.131.52 ||184.108.40.206|
| ||dns1.wcfltx.sbcglobal.net (Wichita Falls) ||220.127.116.11 ||18.104.22.168|
|Illinois ||dns1.chcgil.sbcglobal.net ||22.214.171.124 || |
| ||(Chicago)|| || |
|Indiana ||dns1.ipltin.sbcglobal.net (Indianapolis) ||126.96.36.199|| |
|Michigan ||dns1.klmzmi.sbcglobal.net (Kalamazoo) ||188.8.131.52|| |
| ||dns1.sfldmi.sbcglobal.net (Southfield) ||184.108.40.206|| |
|Ohio ||dns1.bcvloh.sbcglobal.net (Brecksville) ||220.127.116.11|| |
| ||dns1.wotnoh.sbcglobal.net (Worthington) ||18.104.22.168|| |
|Wisconsin ||dns1.milwwi.sbcglobal.net (Milwaukee) ||22.214.171.124|| |
|California ||dns1.bkfdca.sbcglobal.net ||126.96.36.199|| |
| ||(Bakersfield)|| || |
| ||dns1.chicca.sbcglobal.net ||188.8.131.52|| |
| ||(Chico)|| || |
| ||dns1.frsnca.sbcglobal.net ||184.108.40.206|| |
| ||(Fresno)|| || |
| ||dns1.lsanca.sbcglobal.net ||220.127.116.11|| |
| ||(Los Angeles)|| || |
| ||dns1.mtryca.sbcglobal.net ||18.104.22.168|| |
| ||(Monterey)|| || |
| ||dns1.scrmca.sbcglobal.net ||22.214.171.124|| |
| ||(Sacramento)|| || |
| ||dns1.sndgca.sbcglobal.net ||126.96.36.199|| |
| ||(San Diego)|| || |
| ||dns1.snfcca.sbcglobal.net ||188.8.131.52|| |
| ||(San Francisco)|| || |
| ||dns1.snloca.sbcglobal.net ||184.108.40.206|| |
| ||(San Luis Obispo)|| || |
| ||dns1.sntcca.sbcglobal.net ||220.127.116.11|| |
| ||(Santa Clara)|| || |
| ||dns1.sktnca.sbcglobal.net ||18.104.22.168|| |
| ||(Stockton)|| || |
|Nevada||dns1.renonv.sbcglobal.net ||22.214.171.124 || |
| ||(Reno)|| || |
|SBC SNET ||ns1.snet.net ||126.96.36.199|| |
| ||ns2.snet.net ||188.8.131.52|| |
| ||dns1.mrdnct.snet.net ||184.108.40.206|| |
|National Stand Alone ||dns1.nycmny.sbcglobal.net ||220.127.116.11|| |
What is the recommended Routing Protocol?
We recommend that Dedicated Access customers set up a static
default route in their router that points to the appropriate SBCIS hub
router. A static route helps avoid the problems associated with
dynamic routing protocol interactions. If static routes are not
appropriate for your situation (i.e., you have multiple, diverse links to
the Internet), SBCIS will be happy to discuss a more suitable choice
with your local network administrator. Please contact your Internet
Application Manager with such concerns.
Is my network down?
First, check to see if DSU/CSU is showing a red alarm or yellow alarm.
If there is an alarm, there could be a problem with the cable between
the CSU and the NIU. Reseat the cable at the CSU and the NIU and, if
you have a spare, replace the cable. If the problem persists, it may
be a circuit problem.
Some routers have the CSU built in. From your router, try to ping
SBCIS gateway address. If the ping fails, then there is a problem
between your router and our router. Also, try to trace out to a
Web site from your router. The trace will help determine where your
traffic is stopping. The last thing to try is rebooting your router.
This may bring the connection back up. If none of these tips repairs
the problem, please contact our Dedicated Enhanced Service Center
at 1-866-937-3664 (1 866 WE'RE ON IT) or e-mail email@example.com.
TOP OF PAGE
Why is my network running so slow?
First, check to see if the problem is in your local area network or
somewhere past your router toward the Internet. From your router,
trace to a workstation on your local area network. Also do a trace to a
known Web site. Look at the times at each hop. Time over 300 ms
should be researched further. Any routing problems from your router to
the Internet should be reported to our Dedicated Enhanced Service
Center at 1-866-937-3664 (1 866 WE'RE ON IT), and/or paste your traceroutes into e-mail
and send it to firstname.lastname@example.org.
One of our engineers will review the traceroutes and work to fix the problem(s).
What time does the zone transfer occur at SBCIS?
The zone transfer occurs daily at 5:00 a.m., Noon and 5:00 p.m.
I can trace to some places, but not everywhere I used to. Can you tell me why?
Other providers may be having problems, or we may be experiencing
routing difficulties. Run a traceroute to the sites you are having
problems with, then send an e-mail to email@example.com and attach the
TOP OF PAGE
What address should I ping to test if my network is alive?
You can test your site from:
Select the option "ping", enter your address and then click on the "submit" button.
When do you conduct system maintenance?
SBCIS has two maintenance windows a week during which your service
might be interrupted while we upgrade or test our network. Of course
we try to keep service interruptions at a minimum, but there are
occasions when we cannot perform our work without impacting service.
Effective August 1st, 2003, the service windows are:
I can't receive e-mail. All the e-mail's are bounced back.
- Tuesdays, Thursdays, 3:00 A.M. to 6:00 A.M. (Eastern time)
- Tuesdays, Thursdays, 2:00 A.M. to 5:00 A.M. (Central time)
- Tuesdays, Thursdays, 1:00 A.M. to 4:00 A.M. (Mountain time)
- Tuesdays, Thursdays, 12:00 A.M. to 3:00 A.M. (Pacific time)
DNS or mail server is having problems. To check your mail server, try
to telnet to the IP address of your mail server and port 25.
(100.100.100.100 25) If you do not get a reply from telnet, then your
mail server is not answering. Port 25 is where your mail is being sent
from other mail servers. SBCIS will spool your e-mail for up to five (5)
days if your mail server is down. If SBCIS is hosting both your primary
and secondary DNS, call the Network Operations Center to receive
help on this issue.
TOP OF PAGE
Do you have backup e-mail available through SBCIS?
Backup E-mail is available through SBCIS, however, it must be set up
before it will work. If you are authoritative for your domain, that is to
say the InterNIC "whois" points the world to your name servers, you
will have to add a second (or additional) mail server record (MX
record) with a lower priority than your main mail server(s). If our DNS
servers are authoritative for your domain, you will need to request
SBCIS to act as backup to your mail server. You can send a request to
if this was not covered when your account was created.
Should your mail server become unavailable, our server will accept
e-mail for your domain and hold it for approximately five days (space
permitting) until your mail server comes back on line. Senders will get a
"message has not been delivered" message from our server before the
five days are up, but our server will keep trying to reach your server
for a few days before it bounces the mail back to the sender. Our mail
server currently supports the "ETRN" command so you can trigger our
server to attempt delivery of your mail, on demand, rather than wait
for it to get around to checking your server again.
Here is a sample MX record showing how smtp-relay.swbell.net is
configured as a backup mail server to mail.your-domain.com:
- IN MX 10 mail.your-domain.com
- IN MX 100 smtp-relay.swbell.net
TOP OF PAGE
I just changed my DNS files. Why are my users still looking at the
old IP address?
We update our DNS record at 5:00 a.m., Noon and 5:00 p.m. (PST)
daily. Make sure your serial number is updated after you've made the
Why Must I Register My Address and Domain Name?
All Internet IP addresses and Domain Names must be registered to
ensure that there are no duplications. If duplications were to occur,
there would be a great deal of confusion and inaccessibility due to
incorrect host name/IP address, mapping, and routing errors. Such
problems could be extreme and affect many Internet users.
To avoid this, the Internet Addressing and Numbering Authority (IANA)
was established. The IANA has chosen the InterNIC as its service
provider, who in turn has contracted with Network Solutions Inc. (NSI)
to perform the tasks associated with address and name registration.
While this may seem somewhat confusing, the processes are fairly
How Do I Register My Address?
To receive an InterNIC allocated or registered IP address, the policies
of the InterNIC must be followed. SBCIS will be happy to assist
dedicated access customers with this process.
TOP OF PAGE
How Long Will Internet Address Registration Take?
The length of time required to obtain an InterNIC allocated address
depends your specific circumstances. Below are the most common
scenarios and their corresponding time lines. It should be noted that
the re-addressing of the local network cannot begin until the Internet
address assignment process is completed by the InterNIC.
What If I Don't Have a Previously Assigned Internet IP Address?
SBCIS should be able to allocate an IP address out of its existing
address block within two weeks. If your addressing requirements are
very large or unique, addresses may have to be obtained directly from
the InterNIC. This process could take eight weeks depending on how
busy the InterNIC is at the time.
How Do I Get a Previously Assigned Internet Address Block "transferred"
If a dedicated access customer has been allocated an Internet IP
address block by another Internet Service Provider (ISP), agreement
with the ISP must be reached as to whether the addresses can be
transferred. The advantage of transferring IP addresses is that the
customer will not have to re-number all hosts on their local network.
In the best interest of the customer, SBCIS will only accept address
transfers with a legitimate 18-bit network address prefix (subnet
masks of 255.255.192.0) or less. SBCIS may, on an individual case
basis, agree to transfer address assignments with up to a 24-bit
network address prefix (subnet masks of 255.255.255.0). However,
customers requesting such transfers must understand the associated
Specifically, other ISPs may drop these small network entries from
their routing tables as their routing tables reach capacity. Neither
SBCIS nor the InterNIC can mandate that these routes be re-entered
in other ISP routing tables. For this reason, the customer should
thoroughly and carefully evaluate transfers. In order to begin the
transfer process, the customer must obtain written permission from
their previous ISP. These transfers may take up to 8 weeks.
TOP OF PAGE
Can I Get a Previously Assigned Address Replaced by a SBCIS Allocated
Dedicated access customers who have IP addresses from another ISP
will be allocated a SBCIS IP address block upon request. SBCIS should
be able to allocate an IP address out of its existing address block
within two weeks. If your addressing requirements are very large or
unique, they may have to be obtained directly from the InterNIC. This
process could take eight weeks depending on how busy the InterNIC is
at the time.
It is recommended that customers re-numbering their hosts to a SBCIS
allocated address work with their SBCIS Dedicated Service Engineer to
ensure the transition is as smooth as possible.
How Do I Register My Domain Name?
Once you provide us with the completed Domain-Name-Information Form, a DNS Management Administrator will assist you with this process. You can go to www.sbcdomreg.com to initiate the registration on your own, or at your request, we will submit without additional charge to Dedicated Internet Access customers a completed template(s) to SBC E-Services. There is a separate and additional charge to park your chosen domain name. These fees are outlined in table below.
|DNR Pricing for All Regions effective 10/01/02|
Note: Minimum 2 years lease
|Type of Activity||One-Time Price to End-User||End-User Billing|
|New/Change Domain ||Non-recurring charge will no longer be charged for new DNR. Only registration fees apply. This applies if the customers process their own order or if SBC does it.||Not applicable|
|New Domain Registration
||$50 for each domain name on a 2-year lease on the domain name
$75 for each domain name on a 3-year lease on the domain name
$125 for each domain name on a 5-year lease on the domain name
$250 for each domain name on a 10-year lease on the domain name
NOTE: Special Pricing on .to domain name:
$120 for each .to domain name on a 2-year lease on
the domain name
$180 for each .to domain name on a 3-year lease on
the domain name
$300 for each .to domain name on a 5-year lease on
the domain name
$600 for each .to domain name on a 10-year lease on
the domain name
|SBC E-Services Bills via Credit Card (CC) or BTN |
Note - SNET and Neveda only CC billing is available
TOP OF PAGE
What If I Already Have A Registered Domain Name?
Modifications to an existing Domain Names are the responsibility of the administrative and/or technical contact on the existing Domain Name. You can go to www.sbcdomreg.com to initiate a modification to a Domain name with SBC E-Services.
TOP OF PAGE
Classless Inter-Domain Routing (CIDR) Overview
What Is CIDR?
CIDR is a new addressing scheme for the Internet which IP addresses
to be allocated more efficiently when compared to the old Class A, B,
and C address scheme.
Why Do We Need CIDR?
With a new network being connected to the Internet every 30 minutes
the Internet was faced with two critical problems:
Running Out of IP Addresses
- Running out of IP addresses
- Running out of capacity in the global routing tables
There is a maximum number of networks and hosts that can be
assigned unique addresses using the Internet's 32-bit long addresses.
Traditionally, the Internet assigned "classes" of addresses: Class A,
Class B, and Class C were the most common. Each address had two
parts: one part to identify a unique network and the second part to
identify a unique host in that network. Another way the old Class A, B,
and C addresses were identified was by looking at the first 8 bits of
the address and converting it to its decimal equivalent.
|Address Class||# Network Bits||# Hosts Bits||Decimal Address Range
|Class A||8 bits||24 bits||1-126|
|Class B||16 bits||16 bits||128-191|
|Class C||24 bits||8 bits||192-223|
TOP OF PAGE
Using the old Class A, B, and C addressing scheme the Internet could
support the following:
- 126 Class A networks that could include up to 16,777,214 hosts each
- Plus 65,000 Class B networks that could include up to 65,534 hosts each
- Plus over 2 million Class C networks that could include up to 254 hosts each
(Some addresses are reserved for broadcast messages, etc.). Because
Internet addresses were generally only assigned in these three sizes,
there was a lot of wasted addresses. For example, if I needed 100
addresses I would be assigned the smallest address (Class C), but that
still meant 154 unused addresses. The overall result was that while the
Internet was running out of unassigned addresses, only 3% of the
assigned addresses were actually being used. CIDR was developed to
be a much more efficient method of assigning addresses.
TOP OF PAGE
Global Routing Tables At Capacity
A related problem was the sheer size of the Internet global routing
tables. As the number of networks on the Internet increased, so did
the number of routes. A few years back it was forecasted that the
global backbone Internet routers were fast approaching their limit on
the number of routes they could support.
Even using the latest router technology, the maximum theoretical
routing table size is approximately 60,000 routing table entries. If
nothing was done the global routing tables would have reached
capacity by mid-1994 and all Internet growth would be halted.
How Were These Problems Solved?
Two solutions were developed and adopted by the global Internet
Restructuring IP Address Assignments
- Restructuring IP address assignments to increase efficiency
- Hierarchical routing aggregation to minimize route table entries
Classless Inter-Domain Routing (CIDR) is a replacement for the old
process of assigning Class A, B, and C addresses with a generalized
network "prefix". Instead of being limited to network identifiers (or
"prefixes") of 8, 16, or 24 bits, CIDR currently uses prefixes anywhere
from 13 to 27 bits. Thus, blocks of addresses can be assigned for
networks as small as 32 hosts up to networks with over 500,000 hosts
allowing for address assignments that much more closely fit an
organization's specific needs.
TOP OF PAGE
A CIDR address includes the standard 32-bit IP address and also
information on how many bits are used for the network prefix. For
example, in the CIDR address 206.13.01.48/25, the "/25" indicates the
first 25 bits are used to identify the unique network leaving the
remaining bits identify the specific host.
|Prefix|| # Equivalent Class C|| # of Host Addresses
|/27 ||1/8th of a Class C ||32 hosts|
|/26 || 1/4th of a Class C ||64 hosts|
|/25 ||1/2 of a Class C ||128 hosts|
|/24 || 1 Class C ||256 hosts|
|/23 ||2 Class C ||512 hosts|
|/22 ||4 Class C ||1,024 hosts|
|/21 ||8 Class C ||2,048 hosts|
|/20 ||16 Class C ||4,096 hosts|
|/19 ||32 Class C ||8,192 hosts|
|/18 ||64 Class C ||16,384 hosts|
|/17 ||128 Class C ||32,768 hosts|
|/16 ||256 Class C ||65,536 hosts|
| ||(= 1 Class B) || |
|/15 ||512 Class C ||131,072 hosts|
|/14 ||1,024 Class C ||262,144 hosts|
|/13 ||2,048 Class C ||524,288 hosts|
TOP OF PAGE
Hierarchical Routing Aggregation To Minimize Routing Table Entries
The CIDR addressing scheme also enables "route aggregation" in which
a single high-level route entry can represent many lower-level routes
in the global routing tables.
The scheme is similar to the telephone network where the network is
set up in a hierarchical structure. A high-level, backbone network node
only looks at the area code information and then routes the call to the
specific backbone node responsible for that area code. The receiving
node then looks at the phone number prefix and routes the call to its
subtending network node responsible for that prefix and so on. The
backbone network nodes only need routing table entries for area
codes, each representing huge blocks of individual telephone numbers,
not for every unique telephone number.
Currently, big blocks of addresses are assigned to the large Internet
Service Providers (ISPs) who then re-allocate portions of their address
blocks to their customers. For example, SBCIS has been assigned a
CIDR address block with a prefix of /15 (equivalent to 512 Class C
addresses or 131,072 host addresses) and typically assigns its
customers CIDR addresses with prefixes ranging from /27 to /19. These
customers, who may be smaller ISPs themselves, in turn re-allocate
portions of their address block to their users and/or customers.
TOP OF PAGE
However, in the global routing tables all these different networks and
hosts can be represented by the single SBCIS route entry. In this way,
the growth in the number of routing table entries at each level in the
network hierarchy has been significantly reduced. Currently, the global
routing tables have approximately 35,000 entries.
The Internet is currently a mixture of both "CIDR-ized" addresses and
old Class A, B, and C addresses. Almost all new routers support CIDR
and the Internet authorities strongly encourage all users to implement
the CIDR addressing scheme. (We recommend that any new router you
purchase should support CIDR).
The conversion to the CIDR addressing scheme and route aggregation
has two major user impacts:
- Justifying IP Address Assignments
- Where To Get Address Assignments
Even with the introduction of CIDR, the Internet is growing so fast
that address assignments must continue to be treated as a scarce
resource. As such, customers will be required to document, in detail,
their projected needs. Users may be required from time to time to
document their internal address assignments, particularly when
requesting additional addresses. The current Internet guideline is to
assign addresses based on an organization's projected three-month
requirement with additional addresses assigned as needed.
TOP OF PAGE
Where To Get Address Assignments
In the past, you would get a Class A, B or C address assignment
directly from the appropriate Internet Registry (i.e., the InterNIC).
Under this scenario, you "owned" the address and could take it with
you even if you changed Internet Service Providers (ISPs). With the
introduction of CIDR address assignments and route aggregation, with
a few exceptions, the recommended source for address assignments is
your ISP. Under this scenario, you are only "renting" the address and if
you change ISPs it is strongly recommended that you get a new
address from your new ISP and re-number all of your network devices.
While this can be a time consuming task, it is critical for your address
to be aggregated into your ISP's larger address block and routed under
their network address. There are still significant global routing table
issues and the smaller your network the greater your risk of being
dropped from the global routing tables. In fact, networks smaller than
8,192 devices will very likely be dropped. Neither the InterNIC nor
other ISPs have control over an individual ISP's decisions on how to
manage their routing tables.
As an option to physically re-numbering each network device, some
organizations are using proxy servers to translate old network
addresses to their new addresses. Users should be cautioned to
carefully consider all the potential impacts before using this type of
TOP OF PAGE
Need More Information?
For more detailed technical information on CIDR, go to
http://www.rfc-editor.org/rfcsearch.html and type in the number of
the CIDR RFC you are interested in:
- RFC 1517: Applicability Statement for the Implementation of CIDR
- RFC 1518: An Architecture for IP Address Allocation with CIDR
- RFC 1519: CIDR: An Address Assignment and Aggregation Strategy
- RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
As mentioned before, there are a few exceptions where an
organization would not use an ISP assigned address block.
The implementation of CIDR has been critical to the continued growth
of the Internet, allowing more organizations and users to take
advantage of this increasingly vital global networking and information
TOP OF PAGE
Product Overview |
Accounts & Billing |
Service & Support |
Service Provisioning |
Policy & Security |
Contact Us |
Copyright © 2002 SBC Internet Services. All rights reserved.