-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-ietf-softwire-yang-15-inprogress.xml
2521 lines (2178 loc) · 89.8 KB
/
draft-ietf-softwire-yang-15-inprogress.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-softwire-yang-15" ipr="trust200902">
<front>
<title abbrev="YANG Modules for A+P Softwires">YANG Modules for
IPv4-in-IPv6 Address plus Port (A+P) Softwires</title>
<author fullname="Ian Farrer" initials="I." role="editor" surname="Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>CTO-ATI, Landgrabenweg 151</street>
<city>Bonn</city>
<region>NRW</region>
<code>53227</code>
<country>Germany</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." role="editor"
surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="15" month="January" year="2019" />
<workgroup>Softwire Working Group</workgroup>
<keyword>A+P</keyword>
<keyword>address sharing</keyword>
<keyword>port set</keyword>
<keyword>Port range</keyword>
<keyword>IPv4 service continuity</keyword>
<keyword>NETCONF</keyword>
<keyword>RESTCONF</keyword>
<keyword>Programmability</keyword>
<keyword>Dynamic provisioning</keyword>
<keyword>automation</keyword>
<keyword>IPv6</keyword>
<abstract>
<t>This document defines YANG modules for the configuration and
operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises
Equipment for the Lightweight 4over6, Mapping of Address and Port with
Encapsulation (MAP-E), and Mapping of Address and Port using Translation
(MAP-T) softwire mechanisms.</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>Please update these statements within this document with the RFC
number to be assigned to this document:<list style="symbols">
<t>"This version of this YANG module is part of RFC XXXX;"</t>
<t>"RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port
Softwires";</t>
<t>"reference: RFC XXXX"</t>
</list>Please update the "revision" date of the YANG modules.</t>
</note>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>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 address plus
port (A+P) softwire functional elements: Border Routers (BRs) and
Customer Premises Equipment (CEs, a.k.a., CPE). The softwire mechanisms
covered in this document are Lightweight 4 over 6 (lw4o6) <xref
target="RFC7596"></xref>, Mapping of Address and Port with Encapsulation
(MAP-E) <xref target="RFC7597"></xref>, and Mapping of Address and Port
using Translation (MAP-T) <xref target="RFC7599"></xref>.</t>
<t>This document focuses on A+P mechanisms <xref
target="RFC6346"></xref>; the reader can refer to <xref
target="I-D.ietf-softwire-dslite-yang"></xref> for a YANG module for
DS-Lite <xref target="RFC6333"></xref>.</t>
<t>This document defines YANG modules <xref target="RFC7950"></xref>
that can be used to configure and manage A+P softwire elements using the
NETCONF <xref target="RFC6241"></xref>, or RESTCONF <xref
target="RFC8040"></xref> protocols for:</t>
<t><list hangIndent="22" style="symbols">
<t>Configuration</t>
<t>Operational State</t>
<t>Notifications</t>
</list></t>
</section>
<section anchor="terminology" title="Terminology">
<t>The reader should be familiar with the concepts and terms defined in
<xref target="RFC7596"></xref>, <xref target="RFC7597"></xref>, <xref
target="RFC7599"></xref>, and the YANG data modelling language defined
in <xref target="RFC7950"></xref>.</t>
<t>The YANG modules in this document adopt the Network Management
Datastore Architecture (NMDA) <xref target="RFC8342"></xref>. The
meanings of the symbols used in tree diagrams are defined in <xref
target="RFC8340"></xref>.</t>
<t>The document uses the abbrieviation 'BR' as a general term for
softwire tunnel concentrators, including both MAP Border Routers <xref
target="RFC7597"></xref> and Lightweight 4over6 lWAFTRs <xref
target="RFC7596"></xref>.</t>
<t>For brevity, "algorithm" is used to refer to the "mapping algorithm"
defined in <xref target="RFC7597"></xref>.</t>
<t>A network element may support one or multiple instances of a softwire
mechanism; each of these instances (i.e., binding instances, MAP-E
instances, or MAP-T instances) may have its own configuration and
parameters. The term 'algo-instance' is used to denote both MAP-E and
MAP-T instances.</t>
</section>
<section anchor="overview" title="Overview of the Modules">
<section title="Overall Structure">
<t>The document defines the following two YANG modules for the
configuration and monitoring of softwire functional elements:</t>
<t><list hangIndent="22" style="hanging">
<t hangText="ietf-softwire-ce">Provides configuration and
monitoring for softwire CE element. This module is defined as
augments to the interface YANG module <xref
target="RFC8343"></xref>.</t>
<t hangText="ietf-softwire-br">Provides configuration and
monitoring for softwire BR element.</t>
</list></t>
<t>In addition, the following module is defined:</t>
<t><list hangIndent="22" style="hanging">
<t hangText="ietf-softwire-common">Contains groups of common
functions that are imported into the CE and BR modules.</t>
</list></t>
<t>This approach has been taken so that the various modules can be
easily extended to support additional softwire mechanisms, if
required.</t>
<t>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 configuration. For each module, a
choice statement 'ce-type' is included for either 'binding' or
'algorithm'. 'Binding' is used for configuring Lightweight 4over6,
whereas 'algorithm' is used for configuring MAP-T or MAP-E.</t>
<t>In the 'algo-instances' container, a choice statement 'data-plane'
is included to specify MAP-E (encapsulation) or MAP-T (translation).
<xref target="table_s46_mechanism_choices"></xref> shows how these
choices are used to indicate the desired softwire mechanism:</t>
<texttable anchor="table_s46_mechanism_choices"
title="Softwire Mechanism Choice Statement Enumeration">
<ttcol align="center">S46 Mechanism</ttcol>
<ttcol align="center">ce-type?</ttcol>
<ttcol align="center">data-plane?</ttcol>
<c>Lightweight 4over6</c>
<c>binding</c>
<c>n/a</c>
<c>MAP-E</c>
<c>algorithm</c>
<c>encapsulation</c>
<c>MAP-T</c>
<c>algorithm</c>
<c>translation</c>
</texttable>
<t>NETCONF notifications are also included.<list style="empty">
<t>Note: Earlier versions of this specification 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 their role in the
architecture (CE or BR) was a better approach as this follows the
intended function and existing implementation approaches more
closely.</t>
</list></t>
</section>
<section title="Additional Components Configuration">
<t>The softwire modules only aim to provide configuration relevant for
softwires. In order to fully provision a CE element, the following may
also be necessary:</t>
<t><list style="symbols">
<t>IPv6 forwarding and routing configuration, enabling the CE to
obtain one or more IPv6 prefixes for softwire usage. A YANG module
for routing management is described in <xref
target="RFC8349"></xref>.</t>
<t>IPv4 routing configuration, to add one or more IPv4 destination
prefix(es) reachable via the configured softwire. A YANG module
for routing management is described in <xref
target="RFC8349"></xref>.</t>
<t>Stateful NAT44/NAPT management, to optionally specify a port
set (Port Set Identifier (PSID)) along with its length. A YANG
module for NAT management is described in <xref
target="I-D.ietf-opsawg-nat-yang"></xref>.</t>
<t>Stateless NAT46 management, required by softwire translation
based mechanisms (i.e., the assignment of a Network-Specific
Prefix to use for IPv4/IPv6 translation). A YANG module for NAT
management is described in <xref
target="I-D.ietf-opsawg-nat-yang"></xref>.</t>
</list></t>
<t>As YANG modules for the above functions are already defined in
other documents, their functionality is not duplicated here and they
should be referred to, as needed. <xref
target="lw4o6-ce-example"></xref> provides XML examples of how these
modules can be used together.</t>
<t>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 <xref target="RFC8344"></xref> and <xref
target="RFC8349"></xref> may be used.</t>
</section>
</section>
<section anchor="ce-tree-diagram" title="Softwire CE YANG Tree Diagram">
<section title="CE Tree Diagram">
<t>The CE module provides configuration and monitoring for all of the
softwire mechanisms covered in this document (i.e., Lightweight
4over6, MAP-E, and MAP-T).</t>
<t>This module augments "ietf-interfaces", defined in <xref
target="RFC8343"></xref> with an entry for the softwire. This entry
can be referenced to configure IPv4 forwarding features for the
element. This entry is added only if tunnel type (<xref
target="iana"></xref>) is set to 'aplusp'.</t>
<t><xref target="tree-diagram-ce"></xref> shows the tree structure of
the softwire CE YANG module:</t>
<figure align="center" anchor="tree-diagram-ce"
title="Softwire CE YANG Tree Diagram">
<artwork><![CDATA[
module: ietf-softwire-ce
augment /if:interfaces/if:interface:
+--rw softwire-payload-mtu? uint16
+--rw softwire-path-mru? uint16
+--rw (ce-type)?
+--:(binding) {binding-mode}?
| +--rw binding-ipv6info? union
| +--rw br-ipv6-addr inet:ipv6-address
+--:(algo) {map-e or map-t}?
+--rw algo-instances
+--rw algo-instance* [name]
+--rw name string
+--rw enable? boolean
+--rw algo-versioning
| +--rw version? uint64
| +--rw date? yang:date-and-time
+--rw (data-plane)?
| +--:(encapsulation) {map-e}?
| | +--rw br-ipv6-addr inet:ipv6-address
| +--:(translation) {map-t}?
| +--rw dmr-ipv6-prefix? inet:ipv6-prefix
+--rw ea-len uint8
+--rw rule-ipv6-prefix inet:ipv6-prefix
+--rw rule-ipv4-prefix inet:ipv4-prefix
+--rw forwarding boolean
augment /if:interfaces/if:interface/if:statistics:
+--ro sent-ipv4-packets?
| yang:zero-based-counter64
+--ro sent-ipv4-bytes?
| yang:zero-based-counter64
+--ro sent-ipv6-packets?
| yang:zero-based-counter64
+--ro sent-ipv6-bytes?
| yang:zero-based-counter64
+--ro rcvd-ipv4-packets?
| yang:zero-based-counter64
+--ro rcvd-ipv4-bytes?
| yang:zero-based-counter64
+--ro rcvd-ipv6-packets?
| yang:zero-based-counter64
+--ro rcvd-ipv6-bytes?
| yang:zero-based-counter64
+--ro dropped-ipv4-packets?
| yang:zero-based-counter64
+--ro dropped-ipv4-bytes?
| yang:zero-based-counter64
+--ro dropped-ipv6-packets?
| yang:zero-based-counter64
+--ro dropped-ipv6-bytes?
| yang:zero-based-counter64
+--ro dropped-ipv4-fragments?
| yang:zero-based-counter64
+--ro dropped-ipv4-fragment-bytes?
| yang:zero-based-counter64
+--ro ipv6-fragments-reassembled?
| yang:zero-based-counter64
+--ro ipv6-fragments-bytes-reassembled?
| yang:zero-based-counter64
+--ro out-icmpv4-error-packets?
| yang:zero-based-counter64
+--ro out-icmpv4-error-bytes?
| yang:zero-based-counter64
+--ro out-icmpv6-error-packets?
| yang:zero-based-counter64
+--ro out-icmpv6-error-bytes?
yang:zero-based-counter64
notifications:
+---n softwire-ce-event {binding-mode}?
+--ro ce-binding-ipv6-addr-change inet:ipv6-address
]]></artwork>
</figure>
</section>
<section anchor="tree-diagram-ce-desc"
title="Softwire CE Tree Diagram Description">
<t>Additional information related to the operation of a CE element is
provided below:</t>
<t><list style="symbols">
<t>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 Maximum Transit Unit (MTU)
size automatically.</t>
<t>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
payload Maximum Receive Unit (MRU) size automatically (see
Section 3.2 of <xref target="RFC4213"></xref>).</t>
<t>ce-type: provides a choice statement allowing the binding or
algorithmic softwire mechanisms to be selected.</t>
</list></t>
<t>Further details relevant to binding softwire elements are:</t>
<t><list style="symbols">
<t>binding-ipv6info: used to set the IPv6 binding prefix type to
identify which IPv6 address to use as the tunnel source. It can be
'ipv6-prefix' or 'ipv6-address'.</t>
<t>br-ipv6-addr: sets the IPv6 address of the remote BR.</t>
</list></t>
<t>Additional details relevant to some of the important algorithmic
elements are provided below:</t>
<t><list style="symbols">
<t>algo-versioning: optionally used to associate a version number
and/or timestamp to the algorithm. This can be used for
logging/data retention purposes <xref target="RFC7422"></xref>.
The version number is selected to uniquely identify the algorithm
configuration and a new value written whenever a change is made to
the algorithm or a new algo-instance is created.</t>
<t>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. Refer to Section
4.1 of <xref target="RFC7598"></xref>.</t>
<t>ea-len: used to set the length of the Embedded-Address (EA),
which is defined in the mapping rule for a MAP domain.</t>
<t>data-plane: provides a choice statement for either
encapsulation (MAP-E) or translation (MAP-T).</t>
<t>br-ipv6-addr: defines the IPv6 address of the BR. This
information is valid for MAP-E.</t>
<t>dmr-ipv6-prefix: defines the Default Mapping Rule (DMR) IPv6
prefix of the BR. This information is valid for MAP-T.</t>
</list></t>
<t>Additional information on the notification node is listed
below:</t>
<t><list style="symbols">
<t>ce-binding-ipv6-addr-change: if the CE's binding IPv6 address
changes for any reason, the NETCONF client will be notified.</t>
</list></t>
</section>
</section>
<section anchor="br-tree-diagram" title="Softwire BR YANG Tree Diagram">
<section anchor="br-tree-diagram-com" title="BR Tree Diagram">
<t>The BR YANG module provides configuration and monitoring for all of
the softwire mechanisms covered in this document (i.e., Lightweight
4over6, MAP-E, and MAP-T).</t>
<t><xref target="br-structure"></xref> provides the tree structure of
this module:</t>
<figure align="center" anchor="br-structure"
title="Softwire BR YANG Tree">
<artwork><![CDATA[
module: ietf-softwire-br
+--rw br-instances
+--rw (br-type)?
+--:(binding) {binding-mode}?
| +--rw binding
| +--rw bind-instance* [name]
| +--rw name string
| +--rw binding-table-versioning
| | +--rw version? uint64
| | +--rw date? yang:date-and-time
| +--rw softwire-num-max uint32
| +--rw softwire-payload-mtu uint16
| +--rw softwire-path-mru uint16
| +--rw enable-hairpinning? boolean
| +--rw binding-table
| | +--rw binding-entry* [binding-ipv6info]
| | +--rw binding-ipv6info union
| | +--rw binding-ipv4-addr?
| | | inet:ipv4-address
| | +--rw port-set
| | | +--rw psid-offset? uint8
| | | +--rw psid-len uint8
| | | +--rw psid uint16
| | +--rw br-ipv6-addr?
| | inet:ipv6-address
| +--rw icmp-policy
| | +--rw icmpv4-errors
| | | +--rw allow-incoming-icmpv4? boolean
| | | +--rw icmpv4-rate? uint32
| | | +--rw generate-icmpv4-errors? boolean
| | +--rw icmpv6-errors
| | +--rw generate-icmpv6-errors? boolean
| | +--rw icmpv6-rate? uint32
| +--ro traffic-stat
| +--ro discontinuity-time yang:date-and-time
| +--ro sent-ipv4-packets?
| | yang:zero-based-counter64
| +--ro sent-ipv4-bytes?
| | yang:zero-based-counter64
| +--ro sent-ipv6-packets?
| | yang:zero-based-counter64
| +--ro sent-ipv6-bytes?
| | yang:zero-based-counter64
| +--ro rcvd-ipv4-packets?
| | yang:zero-based-counter64
| +--ro rcvd-ipv4-bytes?
| | yang:zero-based-counter64
| +--ro rcvd-ipv6-packets?
| | yang:zero-based-counter64
| +--ro rcvd-ipv6-bytes?
| | yang:zero-based-counter64
| +--ro dropped-ipv4-packets?
| | yang:zero-based-counter64
| +--ro dropped-ipv4-bytes?
| | yang:zero-based-counter64
| +--ro dropped-ipv6-packets?
| | yang:zero-based-counter64
| +--ro dropped-ipv6-bytes?
| | yang:zero-based-counter64
| +--ro dropped-ipv4-fragments?
| | yang:zero-based-counter64
| +--ro dropped-ipv4-fragment-bytes?
| | yang:zero-based-counter64
| +--ro ipv6-fragments-reassembled?
| | yang:zero-based-counter64
| +--ro ipv6-fragments-bytes-reassembled?
| | yang:zero-based-counter64
| +--ro out-icmpv4-error-packets?
| | yang:zero-based-counter64
| +--ro out-icmpv4-error-bytes?
| | yang:zero-based-counter64
| +--ro out-icmpv6-error-packets?
| | yang:zero-based-counter64
| +--ro out-icmpv6-error-bytes?
| | yang:zero-based-counter64
| +--ro dropped-icmpv4-packets?
| | yang:zero-based-counter64
| +--ro dropped-icmpv4-bytes?
| | yang:zero-based-counter64
| +--ro hairpin-ipv4-packets?
| | yang:zero-based-counter64
| +--ro hairpin-ipv4-bytes?
| | yang:zero-based-counter64
| +--ro active-softwire-num?
| uint32
+--:(algo) {map-e or map-t}?
+--rw algorithm
+--rw algo-instance* [name]
+--rw name string
+--rw enable? boolean
+--rw algo-versioning
| +--rw version? uint64
| +--rw date? yang:date-and-time
+--rw (data-plane)?
| +--:(encapsulation) {map-e}?
| | +--rw br-ipv6-addr inet:ipv6-address
| +--:(translation) {map-t}?
| +--rw dmr-ipv6-prefix? inet:ipv6-prefix
+--rw ea-len uint8
+--rw rule-ipv6-prefix inet:ipv6-prefix
+--rw rule-ipv4-prefix inet:ipv4-prefix
+--rw forwarding boolean
+--rw port-set
| +--rw psid-offset? uint8
| +--rw psid-len uint8
| +--rw psid uint16
+--ro traffic-stat
+--ro discontinuity-time yang:date-and-time
+--ro sent-ipv4-packets?
| yang:zero-based-counter64
+--ro sent-ipv4-bytes?
| yang:zero-based-counter64
+--ro sent-ipv6-packets?
| yang:zero-based-counter64
+--ro sent-ipv6-bytes?
| yang:zero-based-counter64
+--ro rcvd-ipv4-packets?
| yang:zero-based-counter64
+--ro rcvd-ipv4-bytes?
| yang:zero-based-counter64
+--ro rcvd-ipv6-packets?
| yang:zero-based-counter64
+--ro rcvd-ipv6-bytes?
| yang:zero-based-counter64
+--ro dropped-ipv4-packets?
| yang:zero-based-counter64
+--ro dropped-ipv4-bytes?
| yang:zero-based-counter64
+--ro dropped-ipv6-packets?
| yang:zero-based-counter64
+--ro dropped-ipv6-bytes?
| yang:zero-based-counter64
+--ro dropped-ipv4-fragments?
| yang:zero-based-counter64
+--ro dropped-ipv4-fragment-bytes?
| yang:zero-based-counter64
+--ro ipv6-fragments-reassembled?
| yang:zero-based-counter64
+--ro ipv6-fragments-bytes-reassembled?
| yang:zero-based-counter64
+--ro out-icmpv4-error-packets?
| yang:zero-based-counter64
+--ro out-icmpv4-error-bytes?
| yang:zero-based-counter64
+--ro out-icmpv6-error-packets?
| yang:zero-based-counter64
+--ro out-icmpv6-error-bytes?
yang:zero-based-counter64
notifications:
+---n softwire-binding-instance-event {binding-mode}?
| +--ro bind-name?
| | -> /br-instances/binding/bind-instance/name
| +--ro invalid-entry* leafref
| +--ro added-entry* inet:ipv6-address
| +--ro modified-entry* leafref
+---n softwire-algorithm-instance-event {map-e, map-t}?
+--ro algo-name
| -> /br-instances/algorithm/algo-instance/name
+--ro invalid-entry-id*
| -> /br-instances/algorithm/algo-instance/name
+--ro added-entry*
| -> /br-instances/algorithm/algo-instance/name
+--ro modified-entry*
-> /br-instances/algorithm/algo-instance/name
]]></artwork>
</figure>
</section>
<section anchor="tree-diagram-br-desc"
title="Softwire BR Tree Diagram Description">
<t>The descriptions for leaves which are common with the CE module are
provided in <xref target="tree-diagram-ce-desc"></xref>. Descriptions
for additional elements are provided below:</t>
<t><list style="symbols">
<t>binding-table-versioning: optionally used to associate a
version number and/or timestamp to the binding table. This can be
used for logging or data retention purposes <xref
target="RFC7422"></xref>. The version number is selected to
uniquely identify the binding table configuration 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.</t>
<t>binding-entry: used to define the binding relationship between
3-tuples {lwB4's IPv6 address/prefix, the allocated IPv4 address,
restricted port-set}. For detail information, please refer to
<xref target="RFC7596"></xref>.</t>
<t>softwire-num-max: used to set the maximum number of softwire
binding rules that can be created on the lw4o6 element
simultaneously. This paramter must not be set to zero because this
is equivalent to disabling the BR instance.</t>
<t>active-softwire-num: holds the number of softwires currently
provisioned on the BR element.</t>
<!---
<t>active (ro): used to show the status of particular
binding-entry.</t>
IF - Commented out as it isn't in the model any more. I forget what the
intended use for this was. Should it be put back in the model, or can
this descrtiption be removed?
-->
</list></t>
<t>Additional information on some of the important notification nodes
is listed below:</t>
<t><list style="symbols">
<t>invalid-entry, added-entry, modified-entry: used to notify the
NETCONF client that a specific binding entry or MAP rule has
expired, been invalidated, added, or modified.</t>
</list></t>
</section>
</section>
<section anchor="ce-yang-module" title="Softwire CE YANG Module">
<t>This module imports the modules defined in <xref
target="RFC6991"></xref>, <xref target="RFC8343"></xref>, and <xref
target="RFC7224"></xref>. It also imports the 'ietf-softwire-common' and
'iana-tunnel-type' modules <xref
target="I-D.ietf-softwire-iftunnel"></xref>.</t>
<figure>
<artwork><![CDATA[<CODE BEGINS>file "[email protected]"
module ietf-softwire-ce {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-softwire-ce";
prefix softwire-ce;
import ietf-inet-types {
prefix inet;
reference "Section 4 of RFC 6991";
}
import ietf-interfaces {
prefix if;
reference "RFC 8343: A YANG Data Model for Interface Management";
}
import ietf-softwire-common {
prefix softwire-common;
reference
"RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port
Softwires";
}
import iana-tunnel-type {
prefix iana-tunnel-type;
reference
"RFC YYYY: Tunnel Interface Types YANG Module";
}
organization
"IETF Softwire Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/softwire/>
WG List: <mailto:[email protected]>
Author: Qi Sun
<mailto:[email protected]>
Author: Linhui Sun
<mailto:[email protected]>
Author: Yong Cui
<mailto:[email protected]>
Editor: Ian Farrer
<mailto:[email protected]>
Author: Sladjana Zoric
<mailto:[email protected]>
Editor: Mohamed Boucadair
<mailto:[email protected]>
Author: Rajiv Asati
<mailto:[email protected]>";
description
"This document defines a YANG module for the configuration and
management of A+P Softwire Customer Premises Equipment (CEs). It
covers Lightweight 4over6, MAP-E, and MAP-T mechanisms.
Copyright (c) 2019 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 Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2019-01-11 {
description
"Initial revision.";
reference
"RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port
Softwires";
}
/*
* Features
*/
feature binding-mode {
description
"Binding is used for configuring the Lightweight 4over6 mechanism.
Binding based softwire mechanisms are IPv4-over-IPv6 tunnelling
transition mechanisms specifically intended for complete
independence between the IPv6 subnet prefix (and IPv6 address)
and IPv4 address, with or without IPv4 address sharing.
This is accomplished by maintaining state for each softwire
(per-subscriber state) in the central Border Relay (BR) and using
a hub-and-spoke forwarding architecture. In order to delegate the
NAPT function and achieve IPv4 address sharing, port-restricted
IPv4 addresses needs to be allocated to CEs.
This feature indicates that the network element can function as
one or more binding based softwire instances.";
reference
"RFC7596: Lightweight 4over6: An Extension to the Dual-Stack Lite
Architecture
RFC7597: Mapping of Address and Port with Encapsulation (MAP-E)
RFC7599: Mapping of Address and Port using Translation (MAP-T)";
}
feature map-e {
description
"MAP-E is an IPv6 transition mechanism for transporting IPv4
packets across an IPv6 network using IP encapsulation. MAP-E
allows for a reduction of the amount of centralized state using
rules to express IPv4/IPv6 address mappings. This introduces an
algorithmic relationship between the IPv6 subnet and IPv4
address.
This feature indicates that the network element can function as
one or more MAP-E softwire instances.";
reference
"RFC7597: Mapping of Address and Port with Encapsulation (MAP-E)";
}
feature map-t {
description
"MAP-T is an IPv6 transition mechanism for transporting IPv4
packets across an IPv6 network using IP translation. It leverages
a double stateless NAT64 based solution as well as the stateless
algorithmic address & transport layer port mapping algorithm
defined for MAP-E.
This feature indicates that the network element can function as
one or more MAP-T softwire instances.";
reference
"RFC7599: Mapping of Address and Port using Translation (MAP-T)";
}
// Binding Entry
grouping binding-entry {
description
"The binding BR (Border Relay) maintains an address binding table
that contains the binding between the CE's IPv6 address,
the allocated IPv4 address and restricted port-set.";
leaf binding-ipv6info {
type union {
type inet:ipv6-address;
type inet:ipv6-prefix;
}
description
"The IPv6 information for a binding entry.
When the IPv6 prefix type is used,
the IPv6 source address of the CE is constructed
according to the description in RFC7596.
If the IPv6 address type is used, the CE can use
any valid /128 address from a prefix assigned to
the CE.";
reference "Section 5.1 of RFC7596.";
}
leaf br-ipv6-addr {
type inet:ipv6-address;
mandatory true;
description
"The IPv6 address of the binding BR.";
}
}
// configuration and stateful parameters for softwire CE interface
augment "/if:interfaces/if:interface" {
when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
description
"Softwire CE interface configuration";
leaf softwire-payload-mtu {
type uint16;
units "bytes";
description
"The payload IPv4 MTU for the softwire tunnel.";
}
leaf softwire-path-mru {
type uint16;
units "bytes";
description
"The path MRU for the softwire (payload + encapsulation
overhead).";
reference
"RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and
Routers";
}
choice ce-type {
description
"Sets the softwire CE mechanism";
case binding {
if-feature "binding-mode";
description
"CE binding configuration";
uses binding-entry;
}
case algo {
if-feature "map-e or map-t";
description
"CE algorithm configuration";
container algo-instances {
description
"Collection of MAP-E/MAP-T parameters";
list algo-instance {
key "name";
description
"MAP forwarding rule instance for
MAP-E/MAP-T";
leaf name {
type string;
mandatory true;
description
"The name is used to uniquely identify an algorithm
instance.
This name can be automatically assigned
or explicitly configured.";
}
uses softwire-common:algorithm-instance;
}
}
}
}
}
augment "/if:interfaces/if:interface/if:statistics" {
when "derived-from(../if:type, 'iana-tunnel-type:aplusp')";
description
"Softwire CE interface statistics.";
uses softwire-common:traffic-stat;
}
/*
* Notifications
*/
notification softwire-ce-event {
if-feature "binding-mode";
description
"CE notification";
leaf ce-binding-ipv6-addr-change {
type inet:ipv6-address;
mandatory true;
description
"This notification is generated whenever the CE's binding IPv6
address changes for any reason.";
}
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section anchor="br-yang-module" title="BR Softwire YANG Module">
<t>This module imports typedefs from <xref target="RFC6991"></xref>. It
also imports the 'ietf-softwire-common' module.</t>
<figure>
<artwork><![CDATA[<CODE BEGINS>file "[email protected]"
module ietf-softwire-br {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-softwire-br";
prefix softwire-br;
import ietf-inet-types {
prefix inet;
reference "Section 4 of RFC 6991";
}
import ietf-yang-types {
prefix yang;
reference "Section 3 of RFC 6991";
}
import ietf-softwire-common {
prefix softwire-common;
reference
"RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port
Softwires";
}
organization
"IETF Softwire Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/softwire/>
WG List: <mailto:[email protected]>
Author: Qi Sun
<mailto:[email protected]>
Author: Linhui Sun
<mailto:[email protected]>
Author: Yong Cui
<mailto:[email protected]>
Editor: Ian Farrer
<mailto:[email protected]>
Author: Sladjana Zoric
<mailto:[email protected]>
Editor: Mohamed Boucadair
<mailto:[email protected]>
Author: Rajiv Asati
<mailto:[email protected]>";
description
"This document defines a YANG module for the configuration and
management of A+P Softwire Border Routers. It covers Lightweight
4over6, MAP-E, and MAP-T mechanisms.
Copyright (c) 2019 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 Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions