]> China Telecom

Guangzhou China zhangf52@chinatelecom.cn

China Telecom

Guangzhou China zhuyq8@chinatelecom.cn

Huawei

China lana.wubo@huawei.com

China Telecom

Guangzhou China hujy5@chinatelecom.cn

Routing Area RTGWG This document defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), SEcure Neighbor Discovery (SEND), and Secure ND Proxy.

This document defines a YANG data model "ietf-ipv6-address-resolution" to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution , redirect function , proxy Neighbor Advertisement , Neighbor Unreachability Detection (NUD) , Duplicate Address Detection , SEcure Neighbor Discovery (SEND), and Secure ND Proxy . Basic neighbor management functionality is supported by the "ietf-ip" YANG data model , and there has already been a draft to extend the basic ARP YANG functionality to cover optional ARP features and related statistics, which is only for IPv4. Thus, an extension for IPv6 address resolution is required to maintain the Neighbor Cache entries for IPv6. specifies the Neighbor Discovery protocol for IPv6 and specifies its related functions. However, the YANG module defined in the document only covers IPv6 address resolution , redirect function , proxy Neighbor Advertisement , NUD , and DAD , along with SEND defined in and Secure ND Proxy defined in . Router and prefix discovery are covered by submodule "ietf-ipv6-router-advertisements" in . Stateless address autoconfiguration is covered by module "ietf-ip" in . The model is based on YANG 1.1 as defined in and conforms to Network Management Datastore Architecture (NMDA) as defined in .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are defined in : configuration system state operational state The following terms are defined in : augment container data model data node leaf list module schema tree The following terms are defined in : Neighbor Discovery Neighbor Advertisement proxy Neighbor Advertisement Neighbor Unreachability Detection The following term is defined in : Duplicate Address Detection Stateless Address Autoconfiguration The following term is defined in : Secure Neighbor Discovery Certification Path Advertisement (CPA) Cryptographically Generated Address (CGA) Nonce Trust Anchor The following term is defined in : Secure ND Proxy

Tree diagrams used in this document follow the notation defined in .

The YANG data model for IPv6 ND defines global configurations and augments the "ietf-ip" for per-interface configuration, which configures and manages IPv6 address resolution and redirect function based on IPv6 ND protocol and other related functions, including proxy Neighbor Advertisement, NUD, DAD, and SEND. Note that the features related to ICMP Router and Prefix Discovery are outside the scope of this module since they have already been defined in the submodule "ietf-ipv6-router-advertisements" , while stateless address autoconfiguration is also out of the scope since it is covered by "ietf-ip".

The data model augments the "/if:interfaces/if:interface/ip:ipv6" path defined in the "ietf-ip" module for IPv6 address resolution based on ND protocol . The "dynamic-discovery" leaf enables the dynamic IPv6 address resolution based on ND protocol. The "ns-interval" leaf defines the interval of retransmitting Neighbor Solicitation messages when the node tries to learn the link-layer address of another node. As for the management of Neighbor Cache entries, the "stale-timeout" leaves define the timeout for STALE entries, while the "age" leaf augments the "/if:interfaces/if:interface/ip:ipv6/ip:neighbor" path to indicate the time that has passed since the last time the Neighbor Cache entry is confirmed reachable. The "statistics" container defines a collection of interface-related statistics about IPv6 ND messages. The "redirect" leaf enables the sending and processing of Redirect messages.

The "proxy-na" container augmenting "ietf-ip" defines the configurations of proxy Neighbor Advertisements , which indicates that a router is willing to accept packets not explicitly addressed to itself. After receiving a Neighbor Solicitation message that the destination address is not its own IPv6 address, a proxy router replies the source with a Neighbor Advertisement message carrying its own link-layer address and the IPv6 address of the original destination. The "inter-vlan-proxy" leaf enables the router to proxy for hosts in the same subnet with different VLANs to enable the communication between them. The "all-proxy" leaf enables the router to proxy for all hosts, that is, responds unconditionally to Neighbor Solicitation messages no matter whether the sources and destinations are in the same subnet or not with its own Neighbor Advertisement messages,which can attract the traffic to the router itself for centralized control or hidding the topology of the network.

The "nud" leaf augmenting "ietf-ip" enables Neighbor Unreachability Detection (NUD) , which is used for a node to track the reachability of the neighbors to which it is sending packets and update the state of the related Neighbor Cache entry. The "reachable-time" leaf defines the time to confirm a neighbor's reachability for NUD. The neighbor's state changes from REACHABLE to STALE when there is no other reachability confirmation from the neighbor in "reachable-time" milliseconds. The "ns-interval" leaf also indicates the interval of retransmitting Neighbor Solicitation messages for NUD.

The "dup-addr-detect-transmits" leaf, which indicates the number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection (DAD) , has already been defined in "ietf-ip" [RFC8344]. The value of the "dup-addr-detect-transmits" leaf can be set to 0 in order to disable DAD. The "ns-interval" leaf also indicates the interval of retransmitting Neighbor Solicitation messages for DAD.

The "secure-nd" container enables the SEND and defines its features of CGA, RSA signature, timestamp, and nonce per interface and per node. The "secure-proxy-nd" enables the secure ND proxy.

This document defines the YANG module "ietf-ipv6-address-resolution", which has the following structure.

This section presents the YANG module of IPv6 Neighbor Discovery defined in this document. This module imports modules from Common YANG Data Types , A YANG Data Model for Interface Management , and A YANG Data Model for IP Management .

file "ietf-ipv6-address-resolution@2025-07-19.yang" module ietf-nd { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-nd"; prefix nd; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix if; reference "RFC 8343: A Yang Data Model for Interface Management"; } import ietf-ip { prefix ip; reference "RFC 8344: A Yang Data Model for IP Management"; } organization "IETF Routing Area Working Group (rtgwg)"; contact "WG Web: WG List: Author: Fan Zhang Author: Yongqing Zhu Author: Bo Wu Author: Jiayuan Hu "; description "This YANG module defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and SEcure Neighbor Discovery (SEND). The model is based on YANG 1.1 as defined in RFC 7950 and conforms to Network Management Datastore Architecture (NMDA) as defined in RFC 8342. Copyright (c) 2025 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, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) RFC4862: IPv6 Stateless Address Autoconfiguration"; revision 2025-07-19 { description "Init revision"; reference "RFC XXXX: YANG Data Model for IPv6 Address Resolution"; } /* Data nodes */ container nd { description "Global parameters for IPv6 address resolution based on IPv6 ND."; leaf stale-timeout { type uint32; units "second"; description "The global timeout for Neighbor Cache entry in the STALE state."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) Section 5.3"; } container secure-nd { description "Global parameters for SEcure Neighbor Discovery (SEND)."; leaf cga-flag { type boolean; description "Flag to indicate whether the node is using CGA."; } leaf minbits { type uint32; default "1024"; description "The minimum acceptable key length for public keys used in the generation of CGAs."; } leaf keypair { type string; description "The public-private key pair used for RSA signatures."; } container RSA-signature-option-reception { description "Parameter for the node that support the reception of the RSA Signature options."; leaf ns-authorization-method { type enumeration { enum trust-anchor { description "The sender's authority is verified via trust anchor."; } enum cga { description "The sender's authority is verified via CGA."; } enum trust-anchor-and-cga { description "Both trust anchor and CGA verification are required."; } enum trust-anchor-or-cga { description "Either trust anchor or CGA verification is required."; } } description "The method to verify the authority of the sender of NS messages."; } leaf na-authorization-method { type enumeration { enum trust-anchor { description "The sender's authority is verified via trust anchor."; } enum cga { description "The sender's authority is verified via CGA."; } enum trust-anchor-and-cga { description "Both trust anchor and CGA verification are required."; } enum trust-anchor-or-cga { description "Either trust anchor or CGA verification is required."; } } description "The method to verify the authority of the sender of NA messages."; } leaf rs-authorization-method { type enumeration { enum trust-anchor { description "The sender's authority is verified via trust anchor."; } enum cga { description "The sender's authority is verified via CGA."; } enum trust-anchor-and-cga { description "Both trust anchor and CGA verification are required."; } enum trust-anchor-or-cga { description "Either trust anchor or CGA verification is required."; } } description "The method to verify the authority of the sender of RS messages."; } leaf ra-authorization-method { type enumeration { enum trust-anchor { description "The sender's authority is verified via trust anchor."; } enum cga { description "The sender's authority is verified via CGA."; } enum trust-anchor-and-cga { description "Both trust anchor and CGA verification are required."; } enum trust-anchor-or-cga { description "Either trust anchor or CGA verification is required."; } } description "The method to verify the authority of the sender of RA messages."; } leaf redirect-authorization-method { type enumeration { enum trust-anchor { description "The sender's authority is verified via trust anchor."; } enum cga { description "The sender's authority is verified via CGA."; } enum trust-anchor-and-cga { description "Both trust anchor and CGA verification are required."; } enum trust-anchor-or-cga { description "Either trust anchor or CGA verification is required."; } } description "The method to verify the authority of the sender of Redirect messages."; } } container timestamp { description "Parameters of Timestamp option."; leaf timestamp-delta { type uint32; units "second"; default "300"; description "The allowed timestamp Delta value."; } leaf timestamp-fuzz { type uint32; units "second"; default "1"; description "The 'fuzz factor' for comparisons."; } leaf timestamp-drift { type uint8; units "percent"; default "1"; description "The allowed clock drift parameter."; } } reference "RFC3971: SEcure Neighbor Discovery (SEND)"; } } augment "/if:interfaces/if:interface/ip:ipv6" { description "Augments interface configuration and state data with parameters of IPv6 address resolution."; container nd { description "Parameters of IPv6 address resolution."; leaf dynamic-discovery { type boolean; default "true"; description "Controls whether dynamic link-layer address resolution for IPv6 on the interface is enabled or disabled. true - dynamic link-layer address resolution based on IPv6 ND is enabled, false - dynamic link-layer address resolution based on IPv6 ND is disabled."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) Section 7.2"; } leaf nud { type boolean; default "true"; description "Controls whether Neighbor Unreachability Detection (NUD) on the interface is enabled or disabled. true - NUD is enabled, false - NUD is disabled."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) Section 7.3"; } leaf reachable-time { type uint32 { range "0..3600000"; } units "millisecond"; description "The time to confirm a neighbor's reachability for NUD."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) - ReachableTime"; } leaf ns-interval { type uint32; units "milliseconds"; description "The interval of retransmitting Neighbor Solicitations to a neighbor for address resolution, NUD, or DAD."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) Section 7.3.3"; } leaf stale-timeout { type uint32; units "second"; description "The timeout for Neighbor Cache entry in the STALE state on the interface."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) Section 5.3"; } leaf redirect { type boolean; default "false"; description "Controls whether sending of ICMP Redirect messages on the interface is enabled or disabled. true - Sending of ICMP Redirect messages is enabled, false - Sending of ICMP Redirect messages is disabled."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) Section 8"; } container proxy-na { description "Parameters of proxy Neighbor Advertisements."; leaf inter-vlan-proxy { type boolean; default "false"; description "Controls whether the router proxies for hosts in the same subnet with different VLANs"; } leaf all-proxy { type boolean; default "false"; description "Controls whether the router proxies for all hosts, that is, responds unconditionally to Neighbor Solicitation with its own Neighbor Advertisement."; } reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) Section 7.2.8"; } container secure-nd { description "Parameters of SEcure Neighbor Discovery (SEND)."; leaf cga-flag { type boolean; description "Flag to indicate whether the interface is using CGA."; } leaf modifier { type inet:ipv6-address; description "Modifier for CGA."; } reference "RFC3971: SEcure Neighbor Discovery (SEND)"; } leaf secure-proxy-nd { type boolean; default "false"; description "Controls whether Secure ND Proxy is enabled or disabled."; reference "RFC6496: Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)"; } container statistics { config false; description "A collection of interface-related statistics about IPv6 ND messages."; leaf in-ns-pkts { type yang:counter32; description "The number of received Neighbor Solicitation packets."; } leaf in-na-pkts { type yang:counter32; description "The number of received Neighbor Advertisement packets."; } leaf in-rs-pkts { type yang:counter32; description "The number of received Router Solicitation packets."; } leaf in-ra-pkts { type yang:counter32; description "The number of received Router Advertisement packets."; } leaf in-redirect-pkts { type yang:counter32; description "The number of received Redirect packets."; } leaf out-ns-pkts { type yang:counter32; description "The number of sent Neighbor Solicitation packets."; } leaf out-na-pkts { type yang:counter32; description "The number of sent Neighbor Advertisement packets."; } leaf out-rs-pkts { type yang:counter32; description "The number of sent Router Solicitation packets."; } leaf out-ra-pkts { type yang:counter32; description "The number of sent Router Advertisement packets."; } leaf out-redirect-pkts { type yang:counter32; description "The number of sent Redirect packets."; } } } } augment "/if:interfaces/if:interface/ip:ipv6/ip:neighbor" { description "Augments IPv6 neighbor list with parameters of IPv6 address resolution based on IPv6 ND."; leaf age { type uint32; units "milliseconds"; config false; description "The time that has passed since receipt of the last reachability confirmation for the neighbor."; reference "RFC4861: Neighbor Discovery for IP version 6 (IPv6) Section 5.1"; } } } ]]>

This document registers a URI in the IETF XML registry . Following the format in , the following registration is requested to be made:

This document registers a YANG module in the YANG Module Names registry .

The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The NETCONF Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: /if:interfaces/if:interface/ip:ipv6/ipv6-addr-res:nd/ipv6-addr-res:dynamic-discovery - This leaf is used to enable IPv6 address resolution, which could allow traffic to be hijacked. /if:interfaces/if:interface/ip:ipv6/ipv6-addr-res:nd/ipv6-addr-res:proxy-na - This subtree is used to enable proxy Neighbor Advertisement on an interface, which could allow spoofing traffic to be injected. /if:interfaces/if:interface/ip:ipv6/ipv6-addr-res:nd/ipv6-addr-res:nud - This leaf could be used to disable NUD on an interface, which could lead to delays in Neighbor Cache updates and cause packets forwarding to unreachable nodes. /if:interfaces/if:interface/ip:ipv6/ipv6-addr-res:nd/ipv6-addr-res:reachable-time - This leaf is used to consider a neighbor reachable since the last confirmation of reachability, which could be set to big values to prolong the effect of spoofing Neighbor Cache entries or small values to cause unnecessary frequent NUDs. /if:interfaces/if:interface/ip:ipv6/ipv6-addr-res:nd/ipv6-addr-res:ns-interval - This leaf is used to set the interval of retransmitting Neighbor Solicitations, which could allow DoS attacks. /ipv6-addr-res:nd/ipv6-addr-res:stale-timeout and /if:interfaces/if:interface/ip:ipv6/ipv6-addr-res:nd/ipv6-addr-res:stale-timeout - These leaves are used to set the timeout for Neighbor Cache entry in the STALE state, which could allow the consumption of cache. Some of the readable data nodes in the ietf-ipv6-nd module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes.

The authors would like to thank Bin Han for the helpful comments and everyone who contributed to the draft.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] SEcure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. This document defines an Experimental Protocol for the Internet community. This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223. This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document obsoletes RFC 7277. This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Huawei Huawei Cisco Systems China Telecom China Telecom This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.

This example illustrates the manual configuration for a Neighbor Cache entry of interface eth0 for peer 2001:db8::2 with link-layer address 00:00:5E:00:53:AB statically. Note: '\' line wrapping per .

eth0 ianaift:ethernetCsmacd 2001:db8::2 00:00:5E:00:53:AB ]]>

This example illustrates the configuration of enabling proxy Neighbor Advertisement, NUD, and DAD with setting the "dup-addr-detect-transmits" leaf as 1, the "reachable-time" leaf as 30000 milliseconds, and the "ns-interval" leaf as 1000 milliseconds. Note: '\' line wrapping per .

eth0 ianaift:ethernetCsmacd 1 true true 30000 1000 1200 true ]]>

Huawei

China hanbin3@huawei.com