YANG Modules for
IPv4-in-IPv6 Address plus Port SoftwiresTsinghua UniversityBeijing100084P.R. China+86-10-6278-5822sunqi.ietf@gmail.comTsinghua UniversityBeijing100084P.R. China+86-10-6278-5822wangh13@mails.tsinghua.edu.cnTsinghua UniversityBeijing100084P.R. China+86-10-6260-3059yong@csnet1.cs.tsinghua.edu.cnDeutsche Telekom AGCTO-ATI,Landgrabenweg 151BonnNRW53227Germanyian.farrer@telekom.deDeutsche Telekom AGLandgrabenweg 151BonnNRW53227Germanysladjana.zechlin@telekom.deOrangeRennes35000Francemohamed.boucadair@orange.comCisco Systems, Inc.7025 Kit Creek Rd.RTPNC27709USARajiva@cisco.comSoftwire Working GroupThis document defines YANG modules for the configuration and
operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises
Equipment. The model covers the Lightweight 4over6, MAP-E, and MAP-T
softwire mechanisms.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 .The IETF Softwire Working Group has developed several IPv4-in-IPv6
softwire mechanisms to address various deployment contexts and
constraints. As a companion to the architectural specification
documents, this document focuses on the provisioning of A+P softwire
functional elements: Border Routers (BRs) and Customer Premises
Equipment (CEs). The softwire mechanisims covered in this document are
Lightweight 4 over 6 , MAP-E , and MAP-T .This document defines YANG data models
that can be used to configure and manage A+P softwire elements using the
NETCONF protocol for:ConfigurationOperational StateNotificationsThe reader should be familiar with the concepts and terms defined
in , ,
, and the YANG data modelling language
defined in and .The meaning of the symbols in tree diagrams is defined in .The document defines these two YANG data modules for the
configuration and monitoring of softwire functional elements:Provides configuration and
monititoring for softwire CE element.Provides configuration and
monititoring for softwire BR element.In addition, the following module is also defined:Contains groups of functions that
are common and are imported into the CE and BR modules.This approach has been taken so that the various modules can be
easily extended to support additional softwire mechanisms, if
required.The modules are defined as augments to the interface YANG module
.Within the BR and CE modules, the YANG "feature" statement is used to
distinguish which of the different softwire mechanism(s) is relevant for
a specific element's configuraiton. For each module, a choice statement
is included for either 'binding' or 'algorithmic'. Binding is used for
configuring Lightweight 4over6, whereas Algorithmic is used for
configuring MAP-T or MAP-E.In the 'algo-instances' container, a choice statement is included to
specify MAP-E (encapsulation) or MAP-T (translation). The following
table shows the how these choices are used to indicate the desired
softwire mechanism:S46 Mechanismce-type?data-plane?Lightweight 4over6bindingn/aMAP-EalgorithmencapsulationMAP-TalgorithmtranslationNETCONF notifications also included.Note: Earlier versions of this document combined the softwire
mechanisms by their associated technologies rather than their
function in the architecture. As the document was revised, it became
apparent that dividing the modules by by their role in the
architecture (CE or BR) was a better approach as this follows the
intended function and existing implmemention approaches more
closely.The softwire module only aims to provide configuration relevant for
softwires. In order to fully specify a CE element, the following may
also be necessary:IPv6 routing configuration, to enable CE to obtain one or more
IPv6 prefixes for softwire usage. YANG module for routing
management is described in IPv4 routing configuration, to add one or more IPv4 destination
prefix(es) reachable via the configured softwire. YANG module for
routing management is described in Stateful NAT44 / NAPT management, to optionally specify a port
set (PSID) along with its length. YANG module for NAT management
is described in
Note thatStateless NAT46 management, required by softwire translation
based mechanisms (i.e. the assignment of a Network-Specific prefix
to use for IPv4/IPv6 translation). YANG module for NAT management
is described in As YANG modules for the configuration for these functions are
already defined in other documents, they are not repeated, but
imported here, as needed.
provides XML examples of how these models can be used together.The CE must already have minimal IPv6 configuration in place so it
is reachable by the Netconf client to obtain softwire configuration.
If additional IPv6 specific configuration is necessary, the YANG
modules defined in and may be used. describes the softwire YANG
module for CE elements. This module augments "ietf-interfaces", defined
in with an entry for the softwire. This
entry can be referenced to configure IPv4 routing for the element.The module provides configuration and monitoring for all of the
softwire mechanisms listed in .Additional information on some of the important CE elements is
provided below:softwire-payload-mtu: optionally used to set the IPv4 MTU for
the softwire. Needed if the softwire implementation is unable to
correctly calculate the correct IPv4 size automatically.softwire-path-mru: optionally used to set the maximum IPv6
softwire packet size that can be received, including the
encapsulation/translation overhead. Needed if the softwire
implementation is unable to correctly calculate the correct IPv4
size automatically.ce-type: provides a choice statement allowing the binding or
algorithmic softwire mechanisms to be selected.Additional details relevant to binding softwire elements are:binding-ipv6info: used to set the IPv6 address type which is
combined in a binding entry, for a complete address or a
prefix.br-ipv6-addr: indicates the IPv6 of the remote BR.Additional details relevant to some of the important algorithmic
elements are provided below:algo-versioning: optionally used to add a incremental version
number and/or timestamp to the algorithm. This can be used for
logging/data retention purposes. The version number is incremented
and a new timestamp value written whenever a change is made to the
algorithm or a new instance is created.forwarding: specifies whether the rule can be used as a Forward
Mapping Rule (FMR). If not set, this rule is a Basic Mapping Rule
(BMR) only and must not be used for forwarding. See Section 4.1 of
.ea-len: used to set the length of the Embedded-Address (EA),
which defined in the mapping rule for a MAP domain.data-plane: provides a choice statement for either
encapsulation (MAP-E) or translation (MAP-T).br-ipv6-addr: defines the IPv6 address of the BR for MAP-E.dmr-ipv6-prefix: defines the Default Mapping Rule (DMR) IPv6
prefix of the BR for MAP-T.stat-count (ro): use to show the numbers of packets and bytes
information of specific element respectively.Additional information on the notification node is listed
below:ce-binding-ipv6-addr-change: if the CE's binding-ipv6-address
changes for any reason, it SHOULD notify the NETCONF client. describes the high level
softwire YANG module for BRs. The module provides configuration and
monitoring for all of the softwire mechanisms listed in .The descriptions for some of the leaves in the BR module are the
same as in . Information on the
additional elements are provided below:binding-table-versioning: optionally used to add an incremental
version number and/or timestamp to the binding table. This can be
used for logging/data retention purposes. The version number is
incremented and a new timestamp value written whenever a change is
made to the contents of the binding table or a new binding table
list is created.binding-entry: used to define the binding relationship between
3-tuples, which contains the lwB4's IPv6 address/prefix, the
allocated IPv4 address and restricted port-set. For detail
information, please refer to .softwire-num-threshold: used to set the maximum number of
softwires that can be created on the lw4o6 element
simultaneously.active-softwire-num (ro): used to present the number of
softwires currently provisioned on the element.active (ro): used to show the status of particular
binding-entry.Additional information on some of the important notification nodes
is listed below:invalid-entry, added-entry, modified-entry: used to notify the
client that a specific binding entry or MAP rule is expired or
invalidated, added, or modified.This module imports typedefs from .This module imports typedefs from .The following YANG module contains definitions that are used by both
the softwire CE and softwire BR YANG modules.The YANG module defined in this document 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
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.All data nodes defined in the YANG modules which can be created,
modified, and deleted (i.e., config true, which is the default) are
considered sensitive. Write operations (e.g., edit-config) applied to
these data nodes without proper protection can negatively affect network
operations.This document requests IANA to register the following URIs in the
"IETF XML Registry" . This document requests that IANA registers the following YANG modules
in the "YANG Module Names" registry .
The authors would like to thank Lishan Li, Bert Wijnen, Giles Heron,
Ole Troan, and Leo Tietz for their contributions to this work.The following sections of the document provide examples on how these
YANG modules could be used for configuring softwire elements.The lwAFTR maintains an address binding table which contains the
following 3-tuples:IPv6 Address for a single lwB4Public IPv4 AddressRestricted port-setThe entry has two functions: the IPv6 encapsulation of inbound IPv4
packets destined to the lwB4 and the validation of outbound
IPv4-in-IPv6 packets received from the lwB4 for de-capsulation.Consider an example for the following lw4o6 binding table
entry:2001:db8::1192.0.2.112382001:db8:1::2A MAP-E BR is configured with forward mapping rules for the clients
it is serving. In this example (taken from , Appendix A, Example 2), the following
parameters are required:Rule IPv6 PrefixRule IPv4 PrefixRule EA-bit bit lengthIPv6 Address of MAP-BRThe mapping rule has two functions: identifying the destination CE
IPv6 address for encapsulating inbound IPv4 packets and the validation
of outbound IPv4-in-IPv6 packets received from the CE for
de-capsulation.The transport type for the data plane also needs to be configured
for encapsulation to enable MAP-E and forwarding needs to be
enabled.Consider an example for the following MAP-E Forwarding Mapping
Rule:encapsulation2001:db8::/40192.0.2.0/24162001:db8:ffff::1Here is the example MAP-E BR configuration xml:The following section provides XML examples for configuring a lw4o6
CE. Examples for routing and NAT44 are also provided for
convienience.Consider an example for the following lw4o6 CE Configuration:2001:db8::1192.0.2.112382001:db8:1::2In the above example, the interface name is defined for the
softwire tunnel. This name is then referenced by the routing
configuration for the IPv4 route. The following section provides
example configuration for the CE's IPv4 routing, using the YANG module
described in .The following section provides example configuration for the CE's
NAPT44 function, using the YANG module described in .