draft-ietf-softwire-dslite-yang-04.txt   draft-ietf-softwire-dslite-yang-05.txt 
Network Working Group M. Boucadair Network Working Group M. Boucadair
Internet-Draft C. Jacquenet Internet-Draft C. Jacquenet
Intended status: Standards Track Orange Intended status: Standards Track Orange
Expires: February 3, 2018 S. Sivakumar Expires: February 11, 2018 S. Sivakumar
Cisco Systems Cisco Systems
August 2, 2017 August 10, 2017
YANG Data Models for the DS-Lite YANG Data Models for the DS-Lite
draft-ietf-softwire-dslite-yang-04 draft-ietf-softwire-dslite-yang-05
Abstract Abstract
This document defines a YANG data model for the DS-Lite Address This document defines YANG data models for the DS-Lite Address Family
Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements .
elements .
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 3, 2018. This Internet-Draft will expire on February 11, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
2. DS-Lite YANG Data Models . . . . . . . . . . . . . . . . . . 3 2. DS-Lite YANG Data Models . . . . . . . . . . . . . . . . . . 4
3. DS-Lite AFTR YANG Module . . . . . . . . . . . . . . . . . . 4 3. DS-Lite AFTR YANG Module . . . . . . . . . . . . . . . . . . 6
4. DS-Lite B4 YANG Module . . . . . . . . . . . . . . . . . . . 10 4. DS-Lite B4 YANG Module . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative references . . . . . . . . . . . . . . . . . . 14 8.1. Normative references . . . . . . . . . . . . . . . . . . 15
8.2. Informative references . . . . . . . . . . . . . . . . . 15 8.2. Informative references . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document defines a data model for DS-Lite [RFC6333], using the This document defines data models for DS-Lite [RFC6333], using the
YANG data modeling language [RFC6020]. Both the Address Family YANG data modeling language [RFC6020]. Both the Address Family
Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements
are covered by this specification. are covered by this specification. As a reminder, Figure 1
illustrates an overview of the DS-Lite architecture that involves
AFTR and B4 elements.
DS-Lite deployment considerations are discussed in [RFC6908]. +-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
| Home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:db8:0:2::1
+--------|||--------+
| AFTR |
|+--------+--------+|
|| Concentrator ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|192.0.2.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|198.51.100.1
+-----+-----+
| IPv4 Host |
+-----------+
This document follows the guidelines of [RFC6087]. Figure 1: DS-Lite Base Architecture
This document uses the common YANG types defined in [RFC6991]. DS-Lite deployment considerations are discussed in [RFC6908].
This document follows the guidelines of [RFC6087], uses the common
YANG types defined in [RFC6991], and adopts Network Management
Datastore Architecture (NMDA).
1.1. Terminology 1.1. Terminology
This document makes use of the terms defined in [RFC6333]. This document makes use of the terms defined in [RFC6333].
The terminology for describing YANG data models is defined in The terminology for describing YANG data models is defined in
[RFC6020]. [RFC6020].
1.2. Tree Diagrams 1.2. Tree Diagrams
skipping to change at page 3, line 16 skipping to change at page 4, line 41
container with presence, and "*" denotes a "list" or "leaf-list". container with presence, and "*" denotes a "list" or "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
2. DS-Lite YANG Data Models 2. DS-Lite YANG Data Models
Figure 1 depicts the YANG data model for the AFTR, while Figure 2 Figure 2 depicts the YANG data model for the AFTR element, while
shows the YANG data model for the B4 element. Figure 3 shows the YANG data model for the B4 element.
The AFTR model supports enabling one or more instances of the AFTR As shown in Figure 1:
function on a device; each instance is responsible for serving a
group of B4s. The data model assumes that each AFTR instance can: be
enable/disabled, be provisioned with dedicated configuration data,
and maintain its own mapping table. The data model assumes that
pools of IPv4 addresses can be provisioned to the AFTR. The AFTR
module augments the NAT module in [I-D.sivakumar-yang-nat].
As such, this document assumes [RFC4787][RFC5382][RFC5508] are o The AFTR element is a combination of an IPv4-in-IPv6
enabled by default. Also, the data model adheres to the encapsualtion/decapsulation function and a NAT function.
recommendations in [RFC6888] and [RFC7857]. Further, the data model
supports state migration as per [RFC7785]. o The B4 element is an IPv4-in-IPv6 encapsulation function.
Therefore, the AFTR YANG module is designed to augment both the
Interfaces YANG module [RFC7223] and the NAT YANG module
[I-D.sivakumar-yang-nat] with DS-Lite specific features. The B4 YANG
module augments the interfaces YANG module.
This document assumes [RFC4787][RFC5382][RFC5508] are enabled by
default. Also, the data model adheres to the recommendations in
[RFC6888] and [RFC7857]. Furthermore, the data model supports state
migration as per [RFC7785].
PCP-related considerations are out of scope of the document. A YANG PCP-related considerations are out of scope of the document. A YANG
data model for PCP is documented in [I-D.boucadair-pcp-yang]. data model for PCP is documented in [I-D.boucadair-pcp-yang].
module: ietf-dslite-aftr module: ietf-dslite-aftr
augment /nat:nat-module/nat:nat-instances/nat:nat-instance: augment /if:interfaces/if:interface:
+--rw ipv6-address? inet:ipv6-address +--rw aftr-ipv6-address? inet:ipv6-address
+--rw ipv4-address? inet:ipv4-address +--rw aftr-ipv4-address? inet:ipv4-address
+--rw tunnel-mtu? uint16 +--rw tunnel-mtu? uint16
+--rw subscriber-mask? uint8
+--rw state-migrate? boolean
+--rw max-softwire-per-subscriber? uint8 +--rw max-softwire-per-subscriber? uint8
+--rw mss-clamping
| +--rw mss-clamping-enable? boolean
| +--rw mss-value? uint16
+--rw v6-v4-dscp-preservation? boolean +--rw v6-v4-dscp-preservation? boolean
augment /nat:nat-module/nat:nat-instances/nat:nat-instance:
+--rw state-migrate? boolean
+--rw mss-clamping
+--rw mss-clamping-enable? boolean
+--rw mss-value? uint16
augment /nat:nat-module/nat:nat-instances/nat:nat-instance/nat:mapping-table/nat:mapping-entry: augment /nat:nat-module/nat:nat-instances/nat:nat-instance/nat:mapping-table/nat:mapping-entry:
+--rw b4-ip-address? inet:ipv6-address +--rw b4-ipv6-address? inet:ipv6-address
+--rw v6-dscp? uint8 +--rw v6-dscp? uint8
+--rw internal-v4-dscp? uint8 +--rw internal-v4-dscp? uint8
+--rw external-v4-dscp? uint8 +--rw external-v4-dscp? uint8
Figure 1: YANG Data Model for DS-Lite AFTR Figure 2: YANG Data Model for DS-Lite AFTR
A B4 instance is provided with the IPv6 address of the AFTR to use,
an (optional) instruction whether DSCP marking is to preserved when
encapsulating an IPv4 packet in an IPv6 packet, and other optional
parameters shown in Figure 3.
module: ietf-dslite-b4 module: ietf-dslite-b4
+--rw dslite-b4 augment /if:interfaces/if:interface:
+--rw enable? boolean +--rw b4-ipv6-address? inet:ipv6-address
+--rw dslite-b4-instances +--rw aftr-ipv6-addr? inet:ipv6-address
+--rw dslite-b4-instance* [id] +--rw b4-ipv4-address? inet:ipv4-address
+--rw id uint32 +--rw tunnel-mtu? uint16
+--rw name? string +--rw v6-v4-dscp-preservation? boolean
+--rw aftr-ipv6-addr inet:ipv6-address
+--rw ipv4-address? inet:ipv4-address
+--rw tunnel-mtu? uint16
+--rw v6-v4-dscp-preservation boolean
Figure 2: YANG Data Model for DS-Lite B4 Figure 3: YANG Data Model for DS-Lite B4
3. DS-Lite AFTR YANG Module 3. DS-Lite AFTR YANG Module
<CODE BEGINS> file "ietf-dslite-aftr@2017-07-27.yang" <CODE BEGINS> file "ietf-dslite-aftr@2017-08-10.yang"
module ietf-dslite-aftr { module ietf-dslite-aftr {
namespace "urn:ietf:params:xml:ns:yang:ietf-dslite-aftr"; namespace "urn:ietf:params:xml:ns:yang:ietf-dslite-aftr";
prefix dslite-aftr; prefix dslite-aftr;
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import ietf-interfaces { prefix if; }
import ietf-nat { import iana-if-type { prefix ianaift; }
prefix nat; import ietf-nat {prefix nat;}
}
organization "Softwire Working Group"; organization "Softwire Working Group";
contact contact
"Mohamed Boucadair <mohamed.boucadair@orange.com> "Mohamed Boucadair <mohamed.boucadair@orange.com>
Christian Jacquenet <christian.jacquenet@orange.com> Christian Jacquenet <christian.jacquenet@orange.com>
Senthil Sivakumar <ssenthil@cisco.com>"; Senthil Sivakumar <ssenthil@cisco.com>";
description description
"This module is a YANG module for DS-Lite AFTR "This module is a YANG module for DS-Lite AFTR
implementations. implementations.
skipping to change at page 5, line 28 skipping to change at page 6, line 41
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2017-08-10 {
description "The module augments also the Interface module.";
reference "-ietf-04";
}
revision 2017-07-27 { revision 2017-07-27 {
description "Redesign the module as an augment of the NAT YANG module."; description "Redesign the module as an augment of the NAT YANG module.";
reference "-ietf-04"; reference "-ietf-04";
} }
revision 2017-07-03 { revision 2017-07-03 {
description "Fix some minor points."; description "Fix some minor points.";
reference "-ietf-03"; reference "-ietf-03";
} }
skipping to change at page 6, line 32 skipping to change at page 7, line 50
revision 2015-08-31 { revision 2015-08-31 {
description "Fix a timeout issue."; description "Fix a timeout issue.";
reference "-01"; reference "-01";
} }
revision 2015-08-17 { revision 2015-08-17 {
description "First spec."; description "First spec.";
reference "-00"; reference "-00";
} }
// Augment NAT module with AFTR parameters // Augment Interface module with DS-Lite Softwire
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:tunnel'";
augment "/nat:nat-module/nat:nat-instances/nat:nat-instance" {
description description
"Augments NAT module with AFTR parameters."; "Augments Interface module with AFTR parameters.
IANA interface types are maintained at this registry:
https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib.
leaf ipv6-address { tunnel (131), -- Encapsulation interface";
leaf aftr-ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IPv6 address of the dslite-aftr."; "IPv6 address of the DS-Lite AFTR.";
reference reference
"RFC 6333."; "RFC 6333.";
} }
leaf ipv4-address { leaf aftr-ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
default "192.0.0.1"; default "192.0.0.1";
description description
"IPv4 address of the DS-Lite AFTR. "IPv4 address of the DS-Lite AFTR.
192.0.0.1 is reserved for the AFTR element. 192.0.0.1 is reserved for the AFTR element.
This address can be used to report ICMP This address can be used to report ICMP
problems and will appear in traceroute problems and will appear in traceroute
outputs."; outputs.";
reference reference
"RFC 6333."; "RFC 6333.";
} }
skipping to change at page 7, line 33 skipping to change at page 9, line 10
simple IPv4-in-IPv6 softwire, it is simple IPv4-in-IPv6 softwire, it is
recommended that the MTU size of the IPv6 recommended that the MTU size of the IPv6
network between the B4 and the AFTR network between the B4 and the AFTR
accounts for the additional overhead accounts for the additional overhead
(40 bytes)."; (40 bytes).";
reference reference
"RFC 6908."; "RFC 6908.";
} }
leaf subscriber-mask { leaf max-softwire-per-subscriber {
type uint8 { type uint8;
range "0 .. 128"; default 1;
}
default "56";
description
"The subscriber-mask is an integer that indicates
the length of significant bits to be applied on
the source IPv6 address (internal side) to
unambiguously identify a CPE.
Subscriber-mask is a system-wide configuration description
parameter that is used to enforce generic "Configures the maximum softwire per subscriber
per-subscriber policies (e.g., port-quota). feature.
The enforcement of these generic policies does not A subscriber is uniquely identified by means
require the configuration of every subscriber's prefix. of subscriber-mask.
Example: suppose the 2001:db8:100:100::/56 prefix is This policy aims to prevent a misbehaving
assigned to a DS-Lite enabled CPE. Suppose also that the subscriber from mounting several DS-Lite
2001:db8:100:100::1 is the IPv6 address used by the softwires that would consume additional AFTR
B4 that resides in that CPE. When the AFTR resources (e.g., get more external ports if
receives a packet from this client, the quota were enforced on a per-softwire basis,
it applies the subscriber-mask (e.g., 56) on consume extra processing due to a large number
the source IPv6 address to compute the associated prefix of active softwires).";
for this client (that is 2001:db8:100:100::/56). Then,
the AFTR enforces policies based on that prefix
(2001:db8:100:100::/56), not on the exact
source IPv6 address";
reference reference
"RFC 7785."; "Section 4 of RFC 7785.";
} }
leaf state-migrate { leaf v6-v4-dscp-preservation {
type boolean; type boolean;
default true;
description description
"State migration is enabled by default."; "Copies the DSCP value from the IPv6 header
and vice versa.
According to Section 2.10 of [RFC6908],
operators should use this model
by provisioning the network such that
the AFTR copies the DSCP value in the IPv4
header to the Traffic Class field in
the IPv6 header, after the encapsulation
for the downstream traffic.";
reference reference
"RFC 7785."; "Section 2.10 of RFC 6908.";
} }
}
// Augment NAT module with AFTR parameters
augment "/nat:nat-module/nat:nat-instances/nat:nat-instance" {
description
"Augments NAT module with AFTR parameters.";
leaf state-migrate {
type boolean;
default true;
leaf max-softwire-per-subscriber {
type uint8;
default 1;
description description
"Configures the maximum softwire per subscriber "State migration is enabled by default.
feature.
A subscriber is uniquely identified by means In the event a new IPv6 address is assigned to the B4 element,
of subscriber-mask. the AFTR should migrate existing state to be bound to the new
IPv6 address. This operation ensures that traffic destined to
the previous B4's IPv6 address will be redirected to the newer
B4's IPv6 address. The destination IPv6 address for tunneling
return traffic from the AFTR should be the last seen as the B4's
IPv6 source address from the CPE.
This policy aims to prevent a misbehaving The AFTR uses the subscriber-mask to determine whether two
subscriber from mounting several DS-Lite IPv6 addresses belong to the same CPE (e.g., if the
softwires that would consume additional AFTR subscriber-mask is set to 56, the AFTR concludes that
resources (e.g., get more external ports if 2001:db8:100:100::1 and 2001:db8:100:100::2 belong to the same
the quota were enforced on a per-softwire basis, CPE assigned with 2001:db8:100:100::/56).";
consume extra processing due to a large number
of active softwires).";
reference reference
"Section 4 of RFC 7785."; "RFC 7785.";
} }
container mss-clamping { container mss-clamping {
description description
"MSS rewriting configuration."; "MSS rewriting configuration to avoid IPv6
fragmentation.";
leaf mss-clamping-enable { leaf mss-clamping-enable {
type boolean; type boolean;
description description
"Enable/disable MSS rewriting feature."; "Enable/disable MSS rewriting feature.";
} }
leaf mss-value { leaf mss-value {
type uint16; type uint16;
units "octets"; units "octets";
description description
"Sets the MSS value to be used for "Sets the MSS value to be used for
MSS rewriting."; MSS rewriting.";
skipping to change at page 9, line 21 skipping to change at page 11, line 9
} }
leaf mss-value { leaf mss-value {
type uint16; type uint16;
units "octets"; units "octets";
description description
"Sets the MSS value to be used for "Sets the MSS value to be used for
MSS rewriting."; MSS rewriting.";
} }
} }
}
leaf v6-v4-dscp-preservation {
type boolean;
description
"Copies the DSCP value from the IPv6 header
and vice versa.
According to Section 2.10 of [RFC6908],
operators should use this model
by provisioning the network such that
the AFTR copies the DSCP value in the IPv4
header to the Traffic Class field in
the IPv6 header, after the encapsulation
for the downstream traffic.";
reference
"Section 2.10 of RFC 6908.";
}
}
// Augment NAT mapping entry: Extended NAT44 mapping Entry // Augment NAT mapping entry: Extended NAT44 mapping Entry
augment "/nat:nat-module/nat:nat-instances/nat:nat-instance/nat:mapping-table/nat:mapping-entry"{ augment "/nat:nat-module/nat:nat-instances/nat:nat-instance/nat:mapping-table/nat:mapping-entry"{
description description
"Augments the NAT mapping table with DS-Lite specifics."; "Augments the NAT mapping tables with DS-Lite specifics.";
leaf b4-ip-address { leaf b4-ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Corresponds to the IPv6 address "Corresponds to the IPv6 address
used by the B4 element."; used by the B4 element.";
reference reference
"RFC 6333."; "RFC 6333.";
} }
leaf v6-dscp { leaf v6-dscp {
type uint8; type uint8;
skipping to change at page 10, line 34 skipping to change at page 12, line 8
description description
"DSCP value of the translated IPv4 packet "DSCP value of the translated IPv4 packet
as marked by the AFTR."; as marked by the AFTR.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. DS-Lite B4 YANG Module 4. DS-Lite B4 YANG Module
<CODE BEGINS> file "ietf-dslite-b4@2017-07-27.yang" <CODE BEGINS> file "ietf-dslite-b4@2017-08-10.yang"
module ietf-dslite-b4 { module ietf-dslite-b4 {
namespace "urn:ietf:params:xml:ns:yang:ietf-dslite-b4"; namespace "urn:ietf:params:xml:ns:yang:ietf-dslite-b4";
prefix dslite-b4; prefix dslite-b4;
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import ietf-interfaces { prefix if; }
import iana-if-type { prefix ianaift; }
organization "Softwire Working Group"; organization "Softwire Working Group";
contact contact
"Mohamed Boucadair <mohamed.boucadair@orange.com> "Mohamed Boucadair <mohamed.boucadair@orange.com>
Christian Jacquenet <christian.jacquenet@orange.com> Christian Jacquenet <christian.jacquenet@orange.com>
Senthil Sivakumar <ssenthil@cisco.com>"; Senthil Sivakumar <ssenthil@cisco.com>";
description description
"This module is a YANG module for DS-Lite B4 implementations. "This module is a YANG module for DS-Lite B4 implementations.
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2017-07-27 { revision 2017-08-10 {
description "Separate B4 from AFTR."; description "Augment the interfaces YANG module.";
reference "-ietf-04"; reference "-ietf-05";
} }
container dslite-b4 { revision 2017-07-27 {
description "Separate B4 from AFTR.";
reference "-ietf-04";
}
description // Augment Interface module with DS-Lite Softwire
"dslite-b4"; augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:tunnel'";
leaf enable { description
type boolean; "Augments Interface module with B4 parameters.
description IANA interface types are maintained at this registry:
"Enable/disable dslite-b4 function."; https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib.
}
container dslite-b4-instances { tunnel (131), -- Encapsulation interface";
description
"dslite-b4 instances";
list dslite-b4-instance { leaf b4-ipv6-address {
key "id"; type inet:ipv6-address;
description
"a dslite-b4 instance.";
leaf id { description
type uint32; "The IPv6 address used by the B4 element.";
description
"dslite-b4 instance identifier.";
}
leaf name { reference
type string; "RFC 6333.";
description }
"A name associated with the dslite-b4 instance.";
}
leaf aftr-ipv6-addr { leaf aftr-ipv6-addr {
type inet:ipv6-address; type inet:ipv6-address;
mandatory true;
description
"The AFTR's IPv6 address.";
reference description
"RFC 6333."; "The AFTR's IPv6 address.";
}
leaf ipv4-address { reference
type inet:ipv4-address; "RFC 6333.";
default "192.0.0.2"; }
description
"IPv4 address of the DS-Lite B4.
192.0.0.0/29 is reserved for the B4 element
[RFC6333].
This address can be used to report ICMP
problems and will appear in traceroute
outputs.";
reference leaf b4-ipv4-address {
"RFC 6333."; type inet:ipv4-address;
} default "192.0.0.2";
leaf tunnel-mtu { description
type uint16; "IPv4 address of the DS-Lite B4.
description 192.0.0.0/29 is reserved for the B4 element
"Configures a tunnel MTU. [RFC6333].
[RFC6908] specifies that since This address can be used to report ICMP
fragmentation and reassembly is not problems and will appear in traceroute
optimal, the operator should do outputs.";
everything possible to eliminate
the need for it. If the operator uses
simple IPv4-in-IPv6 softwire, it is
recommended that the MTU size of the IPv6
network between the B4 and the AFTR
accounts for the additional overhead
(40 bytes).";
reference reference
"RFC 6908."; "RFC 6333.";
} }
leaf v6-v4-dscp-preservation { leaf tunnel-mtu {
type boolean; type uint16;
mandatory true; description
description "Configures a tunnel MTU.
"Copies the DSCP value from the IPv6 header [RFC6908] specifies that since
and vice versa. fragmentation and reassembly is not
According to Section 2.10 of [RFC6908], optimal, the operator should do
operators should use this model everything possible to eliminate
by provisioning the network such that the need for it. If the operator uses
the AFTR copies the DSCP value in the IPv4 simple IPv4-in-IPv6 softwire, it is
header to the Traffic Class field in recommended that the MTU size of the IPv6
the IPv6 header, after the encapsulation network between the B4 and the AFTR
for the downstream traffic."; accounts for the additional overhead
} (40 bytes).";
reference
"RFC 6908.";
}
leaf v6-v4-dscp-preservation {
type boolean;
description
"Copies the DSCP value from the IPv6 header
and vice versa.
According to Section 2.10 of [RFC6908],
operators should use this model
by provisioning the network such that
the AFTR copies the DSCP value in the IPv4
header to the Traffic Class field in
the IPv6 header, after the encapsulation
for the downstream traffic.";
} }
} }
}
} }
<CODE ENDS> }
}
<CODE ENDS>
5. Security Considerations 5. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the support of SSH is mandatory to secure transport layer and the support of SSH is mandatory to
implement secure transport [RFC6242]. The NETCONF access control implement secure transport [RFC6242]. The NETCONF access control
model [RFC6536] provides means to restrict access for particular model [RFC6536] provides means to restrict access for particular
NETCONF users to a pre-configured subset of all available NETCONF NETCONF users to a pre-configured subset of all available NETCONF
protocol operations and contents. protocol operations and contents.
skipping to change at page 15, line 14 skipping to change at page 16, line 37
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>. <http://www.rfc-editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>. <http://www.rfc-editor.org/info/rfc6991>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
8.2. Informative references 8.2. Informative references
[I-D.boucadair-pcp-yang] [I-D.boucadair-pcp-yang]
Boucadair, M., Jacquenet, C., Sivakumar, S., and S. Boucadair, M., Jacquenet, C., Sivakumar, S., and S.
Vinapamula, "YANG Data Models for the Port Control Vinapamula, "YANG Data Models for the Port Control
Protocol (PCP)", draft-boucadair-pcp-yang-04 (work in Protocol (PCP)", draft-boucadair-pcp-yang-04 (work in
progress), May 2017. progress), May 2017.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
 End of changes. 79 change blocks. 
241 lines changed or deleted 301 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/