Softwires (softwire) Internet Drafts

      
 YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires
 
 draft-ietf-softwire-yang-16.txt
 Date: 29/01/2019
 Authors: Ian Farrer, Mohamed Boucadair
 Working Group: Softwires (softwire)
 Formats: txt xml
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. Editorial Note (To be removed by RFC Editor) Please update these statements within this document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: YANG Modules for IPv4-in-IPv6 Address plus Port Softwires"; o "reference: RFC XXXX" Please update the "revision" date of the YANG modules.
 Tunnel Interface Types YANG Module
 
 draft-ietf-softwire-iftunnel-07.txt
 Date: 13/06/2019
 Authors: Mohamed Boucadair, Ian Farrer, Rajiv Asati
 Working Group: Softwires (softwire)
 Formats: xml txt
This document specifies the initial version of a YANG module containing a collection of IANA maintained YANG identities, used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA web site. Tunnel type values are not directly added to the Tunnel Interface Types YANG module; they must instead be added to the "tunnelType" IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly. Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed.

Softwires (softwire)

WG Name Softwires
Acronym softwire
Area Internet Area (int)
State Active
Charter charter-ietf-softwire-05 Approved
Dependencies Document dependency graph (SVG)
Additional URLs
- Wiki
- Issue tracker
Personnel Chairs Ian Farrer
Yong Cui
Area Director Éric Vyncke
Tech Advisor Xing Li
Mailing list Address softwires@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/softwires
Archive https://mailarchive.ietf.org/arch/browse/softwires
Jabber chat Room address xmpp:softwire@jabber.ietf.org?join
Logs https://jabber.ietf.org/logs/softwire/

Charter for Working Group


The Softwires Working Group is specifying the standardization of
discovery, control and encapsulation methods for connecting IPv4
networks across IPv6 networks and IPv6 networks across IPv4 networks
in a way that will encourage multiple, inter-operable
implementations.

For various reasons, native IPv4 and/or IPv6 transport may not be
available in all cases, and there is a need to tunnel IPv4 in IPv6
or IPv6 in IPv4 to cross a part of the network which is not IPv4 or
IPv6 capable. The Softwires Problem Statement, RFC 4925, identifies
two distinct topological scenarios that the Working Group will
provide solutions for: "Hubs and Spokes" and "Mesh." In the former
case (Hubs and Spokes), hosts or "stub" networks are attached via
individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4
softwires to a centralized Softwire Concentrator. In the latter case
(Mesh), network islands of one Address Family (IPv4 or IPv6) are
connected over a network of another Address Family via point to
multi-point softwires among Address Family Border Routers (AFBRs).

The Softwires Working Group will reuse existing technologies as much
as possible and only when necessary, create additional protocol
building blocks.

For generality, all base softwires encapsulation mechanisms should
support all combinations of IP versions over one other (IPv4 over
IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4/IPv6
translation mechanisms, new addressing schemes, and block address
assignments are out of scope. DHCP options developed in this working
group will be reviewed jointly with the DHC Working Group. RADIUS
attributes developed in the Softwires Working Group will be reviewed
jointly with the RADEXT Working Group. The MIB Doctors directorate
will be asked to review any MIB modules developed in the Softwires
Working Group. BGP and other routing and signaling protocols
developed in this group will be reviewed jointly with the proper
working groups and other workings that may take interest (e.g. IDR,
L3VPN, PIM, LDP, SAAG, etc).

The specific work areas for this working group are:

1. Developments for Mesh softwires topology; the Mesh topology work
will be reviewed in the L3VPN and IDR Working Groups
- multicast
- MIB module

2. Developments for 6rd:
- multicast
- operational specification
- RADIUS attribute for 6rd server
- MIB module
- Gateway-initiated 6rd (GI-6rd)

3. Developments for Dual-Stack Lite (DS-Lite):
- multicast
- operational specification
- RADIUS attribute for AFTR
- proxy extensions; GI-DS-Lite; No NAT on AFTR
- MIB module

4. Developments for stateless legacy IPv4 carried over IPv6
- develop a solution motivation document to be published as an
RFC
- develop a protocol specification response to the solution
motivation document; this work item will not be taken through
Working Group last call until the solution motivation document
has been published or approved for publication

5. Finalize discovery and configuration mechanisms for a gateway to
use DS-Lite or 6rd; these discovery and configuration mechanisms
must take into a account other operating environments such as
dual-stack and tunneling mechanisms not defined by the Softwires
Working Group. Development of new mechanisms will involve the
DHC and/or V6OPS Working Groups as appropriate

Other work items would require Working Group approval and rechartering.

Milestones

Date Milestone
Done Submit Mesh topology MIB module document for Proposed Standard
Done Submit DS-lite MIB module document for Proposed Standard
Done Submit stateless legacy IPv4 specification document for Proposed Standard
Done Adopt stateless legacy IPv4 specification document as a Working Group document
Done Submit stateless legacy IPv4 solution motivation document for Informational
Done Adopt Mesh topology MIB module document as a Working Group document
Done Adopt DS-lite MIB module document as a Working Group document
Done Submit Multicast extensions document for Informational
Moved to dhc working group Submit DHCPv4 over tunnel document for Proposed Standard
Done Submit DS-Lite without NAT document for Informational
Done Adopt stateless legacy IPv4 solution motivation document as a Working Group document
Done Submit DS-lite operational document for Informational
Done Adopt Multicast extensions document as a Working Group document
Moved to dhc working group Adopt DHCPv4 over tunnel document as a Working Group document
Done Adopt DS-Lite without NAT document as a Working Group document
Done Submit GI DS-lite document for Proposed Standard
Done Submit 6rd RADIUS attribute document for Proposed Standard
Done Adopt DS-lite operational document as a Working Group document
Done Submit DS-lite RADIUS attribute document for Proposed Standard
Done Submit a problem statement to the IESG to be considered as an Informational RFC
RFC Editor IASA & IETF LLC IETF Trust IRTF IETF IESG IAB IANA Privacy Statement IETF Tools