The PPP NetBIOS Frames Control Protocol (NBFCP)
Extracted elements (24)
Controlling the multicast rate is important because some NetBIOS applications use multicasts to communicate, while other applications do not need multicasts at all. The Multicast-Filtering option allows negotiation to balance these requirements rather than imposing a fixed policy.
NBFCP is only applicable for an end system connecting to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms.
At least four different MAC header implementations exist for NBF packets (802.3 Ethernet, 802.5 Token-Ring, DIX Ethernet, FDDI). The IEEE-MAC-Address-Required option is provided so implementations that need MAC addresses for routing or bridging can negotiate their inclusion; implementations such as NetBIOS gateways may not require any MAC address fields.
A PPP implementation which negotiates the IEEE-MAC-Address-Required option MUST allow reception of PPP NBF packets 12 octets larger than the negotiated MRU size, since NBF packets MAY exceed the negotiated MRU when this option is in effect.
Because NetBIOS name defense takes time (typically a minimum of 3 seconds), it is suggested that if Name-Projection is negotiated, NBFCP timeouts are increased to 10 seconds.
If negotiation about the remote Multicast-Filtering is required and the peer did not provide the option in its Configure-Request, the option SHOULD be appended to a Configure-Nak.
If the IEEE-MAC-Address-Required boolean configuration option is negotiated, all NBF datagrams MUST be sent with the specified 12 octet IEEE MAC address header.
Implementations which do not attempt to add any NetBIOS names MUST Configure-Reject the Name-Projection Configuration Option.
In order to guarantee uniqueness of NetBIOS names on the network, NBFCP requires that end-system implementations MUST negotiate the Name-Projection configuration option.
NBFCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase.
PPP links supporting NBF MUST allow at least 576 octets in the information field of a data link layer frame, since there is no standard method for fragmenting and reassembling NBF datagrams.
The encapsulated NBF packet MUST NOT contain any extra octet padding except when Self-Defining-Padding is negotiated, since NBF datagrams for PPP do not contain a datagram length field.
The restart timer SHOULD default to 10 seconds when configuring NetBIOS names, because adding NetBIOS names can take time (usually 3 seconds) and PPP may default the restart timer to 3 seconds.
When the receiving peer cannot add all requested NetBIOS names, it MUST Configure-Nak with the complete list of names requested, setting the Added field to zero for successfully added names and a non-zero return code for names that could not be added.
NBFCP uses PPP protocol field type hex 803F for control packets. NBF datagrams are encapsulated with protocol field type hex 003F. Only LCP codes 1 through 7 are used; other codes should result in Code-Rejects.
The Name-Projection Added field is a 1-octet dual-role field: in Configure-Request it indicates name type (01 = Unique Name, 02 = Group Name); in Configure-Nak it carries the NetBIOS return code (e.g., 00 = success, 0D = duplicate, 0E = table full, 16 = name in use on remote NetBIOS, 19 = name conflict).
The Peer-class field in Peer-Information identifies the sender's implementation type: 2 = PPP NetBIOS Gateway Server, 4 = PPP Local Access Only Server, 6 = PPP NBF Bridge, 8 = PPP End-System. Values 1, 3, 5, and 7 are reserved for legacy implementations.
NBFCP Configuration Option Type values are assigned as follows: 1 = Name-Projection, 2 = Peer-Information, 3 = Multicast-Filtering, 4 = IEEE-MAC-Address-Required. Up-to-date values are specified in the Assigned Numbers RFC.
The RFC explicitly states that security issues are not discussed in this memo, providing no security analysis for NBFCP.
Before any NBF packets may be communicated, PPP must reach the Network-Layer Protocol phase and NBFCP must reach the Opened state. NBFCP packets received before the Network-Layer Protocol phase is reached should be silently discarded.
The IEEE-MAC-Address-Required boolean option has Type (1 octet, value 4) and Length (1 octet, value 2) with no data field. When negotiated, each NBF datagram is prefixed with a 12-octet IEEE MAC header: 6-octet Destination MAC Address followed by 6-octet Source MAC Address in non-canonical (MSB-first) form.
The Multicast-Filtering Configuration Option has Type (1 octet, value 3), Length (1 octet, value 5), Multicast-Forward-Period (2 octets, 16-bit unsigned, max 60 seconds, 0 = no limit, 0xFFFF = unknown), and Priority (1 octet, 0 = directed packets have priority, 1 = multicast packets have priority).
The Name-Projection Configuration Option consists of a 1-octet Type (value 1), 1-octet Length (2 + number_of_names * 17), zero or more 16-octet NetBIOS-Name fields, and a 1-octet Added field per name indicating name type or return code. At most 14 names can be encoded per option due to the 1-octet length field constraint.
The Peer-Information Configuration Option has Type (1 octet, value 2), Length (1 octet, >=8), Peer-class (1 octet), Peer-version-major (2 octets), Peer-version-minor (2 octets), and optional Peer-name (up to 32 octets). Length of 8 indicates no peer name is present.