1.  Feature Enhancements / Functional Changes

This release provides the following additional DSL Router key features:
 
• IP passthrough support
• Automatic DHCP Server option configuration
• DHCP Server secondary DNS server support


1.1 Security

1.1.1 Telnet
The factory default configuration is for Telnet service domain access, and Telnet login/password validation to be
disabled. Enabling service domain Telnet access must be done from a local console, or a management domain
Telnet CLI session.

The output of the list command does not include the Telnet login IDs and passwords. However, it does include
entries for telnet {disable | enable}, and telnet login {disable | enable}. The action of these commands or the
commands used to change the Telnet login/passwords will not terminate a current service domain Telnet session,
if any. The changes are applied in future service domain Telnet connection and/or login attempts.

It’s not recommend that Telnet in the service domain remain enabled after initial remote configuration, unless
firewalling or other mechanisms are used at the Subscriber Management System to ensure that Telnet access to
the endpoint is limited to the service provider.

1.1.2 Local Console
The factory default configuration is for the local console to be enabled with a default login ID (paradyne), operator
password (abc123), and administrator password (abc123). It is recommended that the user change the login ID
and passwords, and/or disable the local console access during initial setup of the DSL Router. Disabling the local
console will not end an active CLI session for the console, if any, but will refuse future connection attempts. Reenabling
the console must be done via SNMP or a Telnet CLI session.
The output of the list command does not include the local console login ID and password. However, it does include
an entry for console {disable | enable}.

1.1.3 PAP/CHAP
The factory default configuration is for the DSL Router not to negotiate the use of any authentication protocols
nor accept the proposed use of one. When an authentication protocol is used for the PPP session, the DSL Router
is the authenticated party only (i.e., never the authenticator). The output of the list command includes ppp
authentication and ppp username, but not ppp password. Changes to the DSL Router configuration using these
commands does not take affect until the next PPP link establishment (i.e., the PPP session, if any, is not terminated
as a result of the changes).

1.1.4 SNMP
SNMP support is available in the management domain only, therefore the MCP is responsible for the trivial
authentication (community strings) and security checks (source IP address authentication) of the SNMP PDUs
destined for the DSL Router. The MCP serves as the DSL Router’s only trap manager and the MCP is reponsible
for forwarding the DSL Router’s traps to the appropriate actual trap managers configured for the MCP.

1.1.5 Path MTU Discovery
The maximum transmission unit (MTU) of the DSL interface is set to 1492 when PPPoE is enabled to account for
the overhead of the PPPoE/PPP protocol.To eliminate fragmentation or minimize it, it is desirable to know what
is the path MTU along the path from the source to destination. The Path MTU is the minimum of the MTUs of
each hop in the path. RFC 1191 describes a technique for dynamically discovering the maximum transmission unit
(MTU) of an arbitrary internet path.

The “Black Hole” problem described in RFC 2923 occurs because routers don’t always do this correctly. Many
fail to send the necessary ICMP unreachable error (fragmentation required) messages and firewalls are often
misconfigured to suppress all ICMP messages. Path MTU Discovery fails when the appropriate ICMP messages
are not received by the originating host. The upper-layer protocol continues to try to send large packets and,
without the ICMP messages, never discovers that it needs to reduce the size of those packets. These packets
basically disappear into a “black hole”. For example the problem manifests itself as a requested Web page that
doesn’t load. The server continues to send the oversized packet resulting in a partially loaded page and a “waiting
for reply” message in the browser’s status bar.

The real solution to the problem is for the offending routers and firewalls to be corrected. Realistically, this won’t
happen. A workaround is to adjust the MTU value on the local machines. The following sites describe the
procedure as to how this can be done:
• http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/ppp.html#MACOS-WIN98-PPPOEFREEZE
• http://www.cisco.com/warp/public/794/router_mtu.html

1.2 Functional Changes

This release contains the following functional changes:

1.2.1. It is important to note that when the PPP negotiated IP address is assigned, the DSL Router’s configuration
database will automatically be converted to a new configuration determined by this IP address and the interface
to which it is assigned, whether or not IP passthrough is enabled, and whether or not no-dns is selected.  This new
configuration will overwrite the current configuration and be retained during a power reset.

1.2.2. New user interface commands supported (see user’s guide and online help command for details and command
syntax):

– ppp ip {eth1 | dsl1 | passthrough} [mask] [no-dns]
– show pppoe
– dhcp server nameserver ip-addr [ip-addr]
– show dhcp sever

1.2.3 The DHCP Server can now be enabled without specifying a value for the Router option.

1.2.4  NAPT can be enabled with proxy ARP as long as IP passthrough or Basic NAT is also enabled.

1.2.5  When IP passthrough is enabled, the ping/traceroute programs invoked from the DSL Router CLI will not
operate properly if the source IP address used/selected is the IP address of the DSL interface. This is because
session data received on the WAN interface destined for the shared IP address (i.e., the IP address of the
DSL interface) is forwarded to the passthrough LAN device. Using the ping/traceroute program in the management
domain or by using the Ethernet interface IP address as the source IP address will continue to function
properly.

 

NOTE: After upgrading to release M04.04.01, it is not recommended to downgrade to release M04.02.05.  Data will stop passing
if downgrading to M04.02.05 and then upgrading again to M04.04.01. The problem occurs if any configuration changes are made
to enable or disable features (including configuring factory defaults) when M04.02.05 is active. Any new enable/disable features
for M04.04.01 will appear as “disabled” when the release becomes active again.

WARNING: After upgrading to release M04.04.01, it is not recommended to downgrade to release M04.03.04.  If the unit is downgraded
to release M04.03.04, it will fail self test with a 0x4000 result, the ALM LED will stay lit, and the modem will be reconfigured back to
factory defaults.  A power reset of the unit will clear the alarm, but the unit will have to be reconfigured from factory defaults.

For proper operation with an 88xx/86xx DSLAM, this release requires an 8000 IP Conservative MCC, MCC Plus, or MCP with appropriate firmware:

 

Card Type	CCA #	DSLAM
6351 ReachDSL Router	868-4964-8000	N/A
8312 ReachDSL 12 Port Card	868-3426-8000	8610, 8810, 8820
8314 ReachDSL 12 Port Card	868-4427-8000	8620, 8820
8000 IP Conservative MCC	868-3362-80xx (xx = 00, 01, 02, …)	8600, 8800, 8810
8000 IP Conservative MCC Plus	868-3882-80xx (xx = 00, 01, 02, …)	8600, 8800, 8810
8000 IP Conservative MCP	868-3883-80xx (xx = 00, 01, 02, …)	8610, 8620 and 8820

 

Card Type	CCA #	Firmware
8312 ReachDSL 12 Port Card	868-3426-8000	04.02.27 or greater
8314 ReachDSL 12 Port Card	868-4427-8000	04.02.29 or greater
8000 IP Conservative MCC	868-3362-80xx (xx = 00, 01, 02, …)	M04.02.27
8000 IP Conservative MCC Plus	868-3882-80xx (xx = 00, 01, 02, …)	M04.02.27
8000 IP Conservative MCP	868-3883-80xx (xx = 00, 01, 02, …)	M04.02.27

The following are known problems and limitations with this release:

1. NAT Doesn’t Support Out Of Order Fragments) Out of order fragment packets is not support by
    the DSL Router R3 implementation of NAT. This means that it expects the first packet of a fragmented
    stream to be received first prior to the receipt of any other packets of that stream.

2. Hotwire PC Download Program Not working with Windows 2000 (Windows 9x and Windoes NT 4.0 supported)

3. Passive Mode Required for FTP Client Behind DSL Router w/ NAPT or NAT enabled.

4. DSL Router PPPoE Client Support and DSL Link Encapsulation
The PPPoE client feature in the DSL Router is supported only when the DSL link encapsulation is configured for
VNET mode (i.e., EtherHDLC). There are two scenarios where an attempt is made to report a misconfiguration:

4.1. The DSL Router has the PPPoE client enabled, but detects FUNI/MPOA encapsulation on the DSL link
during an attempted link up. In this case, the DSL link will not train up and the port card logs an appropriate
error message to indicate to the user that they must either change the DSL link encapsulation at
the port card or disable the PPPoE client at the DSL Router.

4.2. The DSL Router has already detected FUNI/MPOA encapsulation on the DSL link (i.e., the DSL link is
trained up) and the user attempts to enable the PPPoE client via the CLI. In this case, the pppoe enable
command is rejected with the message "PPPoE client is allowed in VNET mode only."
 

6.1 SNMP MIBs Supported By This Release

This product includes an SNMP agent supporting the following MIBs:
• ianaiftype.mib
• pdn_Arp.mib
• pdn_Config.mib
• pdn_Control.mib
• pdn_DslEndpoint.mib
• pdn_Header.mib
• pdn_HealthAndStatus.mib
• pdn_IfExtConfig.mib
• pdn_NAT.mib
• pdn_dhcp.mib
• pdn_diag.mib
• pdn_inet.mib
• pdn_syslog.mib
• rfc1213.mib
• rfc1573.mib
• rfc2096.mib
• rfc2665.mib
 

AD8810