Definitions of Textual Conventions for Pseudowire (PW) Management
RFC 5542
Document | Type | RFC - Proposed Standard (May 2009) | |
---|---|---|---|
Authors | David Zelig , Thomas Nadeau , Orly Nicklass | ||
Last updated | 2015-10-14 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | Mark Townsley | |
Send notices to | (None) |
RFC 5542
Network Working Group T. Nadeau, Ed. Request for Comments: 5542 BT Category: Standards Track D. Zelig, Ed. Oversi O. Nicklass, Ed. RADVISION May 2009 Definitions of Textual Conventions for Pseudowire (PW) Management Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Nadeau, et al. Standards Track [Page 1] RFC 5542 TC for PW Management May 2009 Abstract This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. Table of Contents 1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Conventions Used in This Document ...............................2 4. Object Definitions ..............................................3 5. Security Considerations .........................................9 6. IANA Considerations .............................................9 7. References .....................................................10 7.1. Normative References ......................................10 7.2. Informative References ....................................10 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines textual conventions used for pseudowire (PW) technology and for Pseudowire Edge-to-Edge Emulation (PWE3) MIB modules. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Nadeau, et al. Standards Track [Page 2] RFC 5542 TC for PW Management May 2009 4. Object Definitions PW-TC-STD-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Unsigned32, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] pwTcStdMIB MODULE-IDENTITY LAST-UPDATED "200904210000Z" -- 21 April 2009 00:00:00 GMT ORGANIZATION "Pseudowire Edge-to-Edge Emulation (PWE3) Working Group" CONTACT-INFO " Thomas D. Nadeau Email: tom.nadeau@bt.com David Zelig Email: davidz@oversi.com Orly Nicklass Email: orlyn@radvision.com The PWE3 Working Group (email distribution pwe3@ietf.org, http://www.ietf.org/html.charters/pwe3-charter.html) " DESCRIPTION "This MIB module defines TEXTUAL-CONVENTIONS for concepts used in pseudowire edge-to-edge networks. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Nadeau, et al. Standards Track [Page 3]quot;inclusion of wildcard NS RRSets in a zone is discouraged, but not barred." [RFC4035] This solution generally scales well. However, since the response will match any address in the wildcard range (/48, /56, /64, etc.), a forward DNS lookup on that response given will not be able to return the same hostname. This method therefore fails the expectation in [RFC1912] for forward and reverse to match. DNSsec [RFC4035] scalability is limited to signing the wildcard zone, which may be satisfactory. 2.3. Dynamic DNS One way to ensure forward and reverse records match is for hosts to update DNS servers dynamically, once interface configuration (whether SLAAC, DHCPv6, or other means) is complete, as described in [RFC4472]. Hosts would need to provide both AAAA and PTR updates, and would need to know which servers would accept the information. This option should scale as well or as poorly as IPv4 dynamic DNS does. Dynamic DNS may not scale effectively in large ISP networks which have no single master name server, but a single master server is not best practice. The ISP's DNS system may provide a point for Denial of Service attacks, including many attempted dDNS updates. Accepting updates only from authenticated sources may mitigate this risk, but only if authentication itself does not require excessive overhead. No authentication of dynamic DNS updates is inherently provided; implementers should consider use of TSIG [RFC2845], or at least ingress filtering so updates are only accepted from customer address space from internal network interfaces, rate limit the number of updates from a customer per second, and consider impacts on scalability. UDP is allowed per [RFC2136] so transmission control is not assured, though the host should expect an ERROR or NOERROR message from the server [RFC2136]; TCP provides transmission control, but the updating host would need to be configured to use TCP. Administrators should consider what domain will contain the records, and who will provide the names. If subscribers provide hostnames, Howard Expires May 19, 2018 [Page 5] Internet-Draft draft-ietf-dnsop-isp-ip6rdns November 2017 they may provide inappropriate strings. Consider "ihate.example.com" or "badword.customer.example.com" or "celebrityname.committed.illegal.acts.example.com." There is no assurance of uniqueness if multiple hosts try to update with the same name ("mycomputer.familyname.org"). There is no standard way to indicate to a host what server it should send dDNS updates to; the master listed in the SOA is often assumed to be a dDNS server, but this may not scale. 2.3.1. Dynamic DNS from Individual Hosts In the simplest case, a residential user will have a single host connected to the ISP. Since the typical residential user cannot configure IPv6 addresses and resolving name servers on their hosts, the ISP should provide address information conventionally (i.e., their normal combination of RAs, DHCP, etc.), and should provide a DNS Recursive Name Server and Domain Search List as described in [RFC3646] or [RFC6106]. In determining its Fully Qualified Domain Name, a host will typically use a domain from the Domain Search List. This is an overloading of the parameter; multiple domains could be listed, since hosts may need to search for unqualified names in multiple domains, without necessarily being a member of those domains. Administrators should consider whether the domain search list actually provides an appropriate DNS suffix(es) when considering use of this option. For purposes of dynamic DNS, the host would concatenate its local hostname (e.g., "hostname") plus the domain(s) in the Domain Search List (e.g., "customer.example.com"), as in "hostname.customer.example.com." Once it learns its address, and has a resolving name server, the host must perform an SOA lookup on the ip6.arpa record to be added, to find the owner, eventually to find the server authoritative for the zone (which might accept dynamic updates). Several recursive lookups may be required to find the longest prefix which has been delegated. The DNS administrator must designate the Primary Master Server for the longest match required. Once found, the host sends dynamic AAAA and PTR updates using the concatenation defined above ("hostname.customer.example.com"). In order to use this alternative, hosts must be configured to use dynamic DNS. This is not default behavior for many hosts, which is an inhibitor for the large ISP. This option may be scalable, although registration following an outage may cause significant load, and hosts using privacy extensions [RFC4941] may update records daily. It is up to the host to provide matching forward and reverse records, and to update them when the address changes. Howard Expires May 19, 2018 [Page 6] Internet-Draft draft-ietf-dnsop-isp-ip6rdns November 2017 2.3.2. Dynamic DNS through Residential Gateways Residential customers may have a gateway, which may provide DHCPv6 service to hosts from a delegated prefix. ISPs should provide a DNS Recursive Name Server and Domain Search List to the gateway, as described above and in [RFC3646] and [RFC6106]. There are two options for how the gateway uses this information. The first option is for the gateway to respond to DHCPv6 requests with the same DNS Recursive Name Server and Domain Search List provided by the ISP. The alternate option is for the gateway to relay dynamic DNS updates from hosts to the servers and domain provided by the ISP. Host behavior is unchanged; the host sends the same dynamic updates, either to the ISP's server (as provided by the gateway), or to the gateway for it to forward. 2.3.3. Automatic DNS Delegations An ISP may delegate authority for a subdomain such as "customer12345.town.AW.customer.example.com" or "customer12345.example.com" to the customer's gateway. Each domain thus delegated must be unique within the DNS. The ISP may also then delegate the ip6.arpa zone for the prefix delegated to the customer, as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa." Then the customer could provide updates to their own gateway, with forward and reverse. However, individual hosts connected directly to the ISP rarely have the capability to run DNS for themselves; therefore, an ISP can only delegate to customers with gateways capable of being authoritative name servers. If a device requests a DHCPv6 Prefix Delegation, that may be considered a reasonably reliable indicator that it is a gateway, rather than an individual host. It is not necessarily an indicator that the gateway is capable of providing DNS services, and therefore cannot be relied upon as a way to test whether this option is feasible. In fact, this kind of delegation will not work for devices complying with [RFC6092], which includes the requirement, "By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server." If the customer's gateway is the name server, it provides its own information to hosts on the network, as often done for enterprise networks, and as described in [RFC2136]. An ISP could provide authoritative responses as a secondary server to the customer's master server. For instance, the home gateway name server could be the master server, with the ISP providing the only published NS authoritative servers. Howard Expires May 19, 2018 [Page 7] Internet-Draft draft-ietf-dnsop-isp-ip6rdns November 2017 To implement this alternative, users' residential gateways must be capable of acting as authoritative name servers capable of dynamic DNS updates. There is no mechanism for an ISP to dynamically communicate to a user's equipment that a zone has been delegated, so user action would be required. Most users have neither the equipment nor the expertise to run DNS servers, so this option is unavailable to the residential ISP. 2.3.4. Generate Dynamic Records An ISP's name server that receives a dynamic forward or reverse DNS update may create a matching entry. Since a host capable of updating one is generally capable of updating the other, this should not be required, but redundant record creation will ensure a record exists. ISPs implementing this method should check whether a record already exists before accepting or creating updates. This method is also dependent on hosts being capable of providing dynamic DNS updates, which is not default behavior for many hosts. 2.3.5. Populate from DHCP Server A ISP's DHCPv6 server may populate the forward and reverse zones when the DHCP request is received, if the request contains enough information. [RFC4704] However, this method will only work for a single host address (IA_NA); the ISP's DHCP server would not have enough information to update all records for a prefix delegation. If the zone authority is delegated to a home gateway which used this method, the gateway could update records for residential hosts. To implement this alternative, users' residential gateways would have to support the FQDN DHCP option, and would have to either have the zones configured, or send dDNS messages to the ISP's name server. 2.3.6. Populate from RADIUS Server A user may receive an address or prefix from a RADIUS [RFC2865] server, the details of which may be recorded via RADIUS Accounting [RFC2866] data. The ISP may populate the forward and reverse zones from the accounting data if it contains enough information. This solution allows the ISP to populate data concerning allocated prefixes (as per 2.2 (wildcards)) and CPE endpoints, but as with 2.3.5 does not allow the ISP to populate information concerning individual hosts. RFC 5542 TC for PW Management May 2009 - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of this MIB module is part of RFC 5542; see the RFC itself for full legal notices." -- Revision history. REVISION "200904210000Z" -- 21 April 2009 00:00:00 GMT DESCRIPTION "Original Version" ::= { mib-2 188 } PwGroupID ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "An administrative identification for grouping a set of service-specific pseudowire services." SYNTAX Unsigned32 PwIDType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current Nadeau, et al. Standards Track [Page 4] RFC 5542 TC for PW Management May 2009 DESCRIPTION "Pseudowire Identifier. Used to identify the PW (together with some other fields) in the signaling session." SYNTAX Unsigned32 PwIndexType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Pseudowire Index. A unique value, greater than zero, for each locally defined PW. Used for indexing several MIB tables associated with the particular PW. It is recommended that values are assigned contiguously starting from 1. The value for each PW MUST remain constant at least from one re-initialization to the next re-initialization." SYNTAX Unsigned32 (1..4294967295) PwIndexOrZeroType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "This TEXTUAL-CONVENTION is an extension of the PwIndexType convention. The latter defines a greater- than-zero value used to identify a pseudowire in the managed system. This extension permits the additional value of zero. The zero value is object-specific and MUST therefore be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where pseudowire was unknown, or where none or all pseudowires need to be referenced." SYNTAX Unsigned32 (0..4294967295) PwOperStatusTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the operational status of the PW. - up(1): Ready to pass packets. - down(2): PW signaling is not yet finished, or indications available at the service level indicate that the PW is not passing packets. - testing(3): AdminStatus at the PW level is set to test. Nadeau, et al. Standards Track [Page 5] RFC 5542 TC for PW Management May 2009 - dormant(4): The PW is not in a condition to pass packets but is in a 'pending' state, waiting for some external event. - notPresent(5): Some component is missing to accomplish the setup of the PW. It can be configuration error, incomplete configuration, or a missing H/W component. - lowerLayerDown(6): One or more of the lower-layer interfaces responsible for running the underlying PSN is not in OperStatus 'up' state." SYNTAX INTEGER { up(1), down(2), testing(3), dormant(4), notPresent(5), lowerLayerDown(6) } PwAttachmentIdentifierType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An octet string used in the generalized Forward Error Correction (FEC) element for identifying attachment forwarder and groups. A NULL identifier is of zero length. " SYNTAX OCTET STRING (SIZE (0..255)) PwGenIdType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the Attachment Group Identifier (AGI) Type and Attachment Individual Identifier (AII) Type in generalized FEC signaling and configuration. " SYNTAX Unsigned32( 0..254 ) PwCwStatusTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the status of the control word (CW) negotiation based on the local configuration and the indications received from the peer node. waitingForNextMsg(1) indicates that the node is waiting for another label mapping from the peer. Nadeau, et al. Standards Track [Page 6] RFC 5542 TC for PW Management May 2009 sentWrongBitErrorCode(2) indicates that the local node has notified the peer about a mismatch in the C-bit. rxWithdrawWithWrongBitErrorCode(3) indicates that a withdraw message has been received with the wrong C-bit error code. illegalReceivedBit(4) indicates a C-bit configuration with the peer that is not compatible with the PW type. cwPresent(5) indicates that the CW is present for this PW. If signaling is used, the C-bit is set and agreed upon between the nodes. For manually configured PW, the local configuration requires the use of the CW. cwNotPresent(6) indicates that the CW is not present for this PW. If signaling is used, the C-bit is reset and agreed upon between the nodes. For manually configured PW, the local configuration requires that the CW not be used. notYetKnown(7) indicates that a label mapping has not yet been received from the peer. " REFERENCE "Martini, et al., 'Pseudowire Setup and Maintenance Using the Label Distribution Protocol', [RFC4447]." SYNTAX INTEGER { waitingForNextMsg(1), sentWrongBitErrorCode(2), rxWithdrawWithWrongBitErrorCode(3), illegalReceivedBit(4), cwPresent(5), cwNotPresent(6), notYetKnown(7) } PwStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the status of the PW and the interfaces affecting this PW. If none of the bits are set, it indicates no faults are reported. " Nadeau, et al. Standards Track [Page 7] RFC 5542 TC for PW Management May 2009 SYNTAX BITS { pwNotForwarding(0), servicePwRxFault(1), servicePwTxFault(2), psnPwRxFault(3), psnPwTxFault(4) } PwFragSize ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "If set to a value other than zero, it indicates the desired fragmentation length in bytes. If set to zero, fragmentation is not desired for PSN bound packets. " SYNTAX Unsigned32 PwFragStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates the status of the fragmentation/reassembly process based on local configuration and peer capability. noFrag(0) bit indicates that local configuration is for no fragmentation. cfgFragGreaterThanPsnMtu(1) bit indicates that the local node is set to fragment, but the fragmentation size is greater than the MTU available at the PSN between the nodes. Fragmentation is not done in this case. cfgFragButRemoteIncapable(2) bit indicates that the local configuration conveys the desire for fragmentation but the peer is not capable of reassembly. remoteFragCapable(3) bit indicates that the remote node is capable to accept fragmented PDUs. fragEnabled(4) bit indicates that fragmentation will be used on this PW. Fragmentation can be used if the local node was configured for fragmentation, the peer has the capability to accept fragmented packets, and the CW is in use for this PW." REFERENCE "Malis, A. and M. Townsley, 'Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly', [RFC4623]." Nadeau, et al. Standards Track [Page 8] RFC 5542 TC for PW Management May 2009 SYNTAX BITS { noFrag(0), cfgFragGreaterThanPsnMtu(1), cfgFragButRemoteIncapable(2), remoteFragCapable(3), fragEnabled(4) } PwCfgIndexOrzero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Index in any of the relevant configuration tables for supplement information regarding configuration of the specific technology. Value zero implies no additional configuration information is applicable." SYNTAX Unsigned32 (0..4294967295) END 5. Security Considerations This module does not define any management objects. Instead, it defines a set of textual conventions that may be used by other PWE3 MIB modules to define management objects. Meaningful security considerations can only be written in the MIB modules that define management objects. Therefore, this document has no impact on the security of the Internet. 6. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pwTcStdMIB { mib-2 188 } Nadeau, et al. Standards Track [Page 9] RFC 5542 TC for PW Management May 2009 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006. 7.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Nadeau, et al. Standards Track [Page 10] RFC 5542 TC for PW Management May 2009 Authors' Addresses Thomas D. Nadeau (editor) BT BT Centre 81 Newgate Street London EC1A 7AJ United Kingdom EMail: tom.nadeau@bt.com David Zelig (editor) Oversi Networks 1 Rishon Letzion St. Petah Tikva Israel Phone: +972 77 3337 750 EMail: davidz@oversi.com Orly Nicklass (editor) RADVISION 24 Raul Wallenberg Tel Aviv Phone: +972 3 776 9444 EMail: orlyn@radvision.com Nadeau, et al. Standards Track [Page 11]