Subject: registering tunnel types

From: tom petch <[email-masked]>
Date: Wed, 24 Oct 2018 15:57:49 +0000

draft-ietf-softwire-yang
completed IETF Last Call two weeks ago and, since then, has acquired a
YANG module that defines tunnel types, as listed below.  It is intended
to be a IANA-maintained module and so changes to the list of tunnels
will not require a reissue of the softwires RFC-to-be.  At the same
time, getting it right first time never did any harm so if anyone can
think of any missing, or can think of other places where there might be
other tunnels lurking, now would be a good time to mention it.

It is based on RFC4087 Tunnel MIB (which created an SMI Textual
Convention that went up to Teredo) so tunnels from that vintage are
likely well catered for.  softwires is not where I would have first
looked for tunnel types, but it has a certain logic to it.

     identity  other

     identity direct

     identity gre

     identity minimal

     identity l2tp

     identity pptp

     identity l2f

     identity udp

     identity atmp

     identity msdp

     identity sixtofour

     identity sixoverfour

     identity isatap

     identity teredo

     identity iphttps

     identity softwiremesh

     identity dslite

     identity  aplusp

Tom Petch

---

From: Sander Steffann <[email-masked]>
Date: Wed, 24 Oct 2018 21:38:57 +0200

Hi,

>     identity  aplusp

There are many protocols based on the A+P concept which differ in provisioning style and encapsulation/translation, so I'm not sure they can be grouped like this. From the top of my head the most commonly used ones are, in order of RFC number:

Lw4over6 [rfc7596]: per-customer mapping between IPv4 and IPv6 addresses, transported as IPv4 encapsulated in IPv6
MAP-E [rfc7597]: algorithmic mapping between IPv4 and IPv6 addresses, transported as IPv4 encapsulated in IPv6
MAP-T [rfc7599]: algorithmic mapping between IPv4 and IPv6 addresses, IPv4 transported as IPv6 packets using SIIT

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Oct 2018 09:53:39 +0200

Are:
-IPv6 in UDPv4 and
-IPv6 in IPv6 as used by openvpn;

covered by the list below?

These are a few tunnelling mechanisms I use routinely.

Existing identity 6tofour should be deprecated, if that means 6to4, 
which is deprecated.

Existing identity iphttps has a version number for IP?

Alex

Le 24/10/2018 à 17:57, tom petch a écrit :
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Oct 2018 09:57:44 +0200

why do you say 'sixtofour' and not '6to4'?  If that is a YANG software 
problem then it should be fixed.  If it is just a nicer manner to write 
text then I think it is a little bit confusing to me.

(there are similar problems with xml2rfc which cant reference '3gpp' 
documents because starting with a number;  I guess fixing one would help 
fix the other).

Alex

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2018 09:43:27 -0400

> covered by the list below?

Since there is a layer of proprietary encryption in openvpn, the answer is
no.

---

From: tom petch <[email-masked]>
Date: Fri, 26 Oct 2018 11:47:45 +0000

----- Original Message -----
From: "Sander Steffann" <[email-masked]>
Sent: Wednesday, October 24, 2018 8:38 PM

Hi,

>     identity  aplusp

There are many protocols based on the A+P concept which differ in
provisioning style and encapsulation/translation, so I'm not sure they
can be grouped like this. From the top of my head the most commonly used
ones are, in order of RFC number:

Lw4over6 [rfc7596]: per-customer mapping between IPv4 and IPv6
addresses, transported as IPv4 encapsulated in IPv6
MAP-E [rfc7597]: algorithmic mapping between IPv4 and IPv6 addresses,
transported as IPv4 encapsulated in IPv6
MAP-T [rfc7599]: algorithmic mapping between IPv4 and IPv6 addresses,
IPv4 transported as IPv6 packets using SIIT

<tp>

Thanks for that.  The irony is that this YANG module appears in an I-D
which caters for the management of MAP-E, MAP-T and Lw4o6 so if anyone
would want to differentiate the three, it should be this I-D!  In fact,
the I-D is structured as a module for CPE (all three types), one for BR
(all three  types) and a common module, using if-feature to then refine
the tunnel type so it uses aplusp and no more.

Tom Petch

Cheers,
Sander

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 10:43:26 +0000

Hi Tom, all,

In order to provide a full context, below some precisions: 

* draft-ietf-softwire-yang DOES NOT create a new registry for maintaining tunnel types nor changes the procedure to assign new code points.  Such register does already exist: https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6. 
* draft-ietf-softwire-yang creates a YANG module which **maintained by IANA**; that is, upon assignment of a new code by IANA, the module is updated automatically by IANA. 
* draft-ietf-softwire-yang augments the interface YANG module with aplusp specific nodes. To do so, it requires the tunnel type to be set to aplusp. 

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de tom petch
> Envoyé : mercredi 24 octobre 2018 17:58
> À : Ole Troan
> Cc : 6man WG
> Objet : registering tunnel types
> 
> draft-ietf-softwire-yang

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 12:08:51 +0000

Hi Sander, 

All those A+P flavors are discussed in draft-ietf-softwire-yang. 

For what we are doing in the draft, we don't need to assign a tunnel type value for each of them. One single aplusp value is sufficient. We do have features to cover specificities (map-e, map-t, and lw4o6). 

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Sander Steffann
> Envoyé : mercredi 24 octobre 2018 21:39
> À : tom petch
> Cc : 6man WG
> Objet : Re: registering tunnel types
> 
> Hi,
> 
> >     identity  aplusp
> 
> provisioning style and encapsulation/translation, so I'm not sure they can be
> grouped like this. From the top of my head the most commonly used ones are,
> in order of RFC number:
>

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 12:15:11 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 26 octobre 2018 13:48
> À : Sander Steffann
> Cc : 6man WG
> would want to differentiate the three, it should be this I-D!

[Med] No sure to understand the point. The document differentiates between the various flavors, but when it comes to augmenting the interface YANG module it only needs to check that a given tunnel is an A+P one. This is what is covered by this line:

when "derived-from(if:type, 'iana-tunnel-type:aplusp')";

This approach is optimal compared to assigning multiple values and having a test on the following:
 
iana-tunnel-type:mape or iana-tunnel-type:lw4o6 or ... 

  In fact,
> the tunnel type so it uses aplusp and no more.

[Med] What is the problem with this design?

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 12:19:07 +0000

Alex, 

draft-ietf-softwire-yang relies on an existing registry: : https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6. So, the list cited by Tom is from that registry. draft-ietf-softwire-yang is only echoing those values. 

If you need a new value or if you have a question about a given interface tunnel type, please follow the guidelines in the url cited above. All this is out of the scope of draft-ietf-softwire-yang.

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Alexandre Petrescu
> Envoyé : jeudi 25 octobre 2018 09:54
> À : [email-masked]

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 12:19:56 +0000

Re-,

Please check https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6 for your questions. 

Cheers,
Med

> Envoyé : jeudi 25 octobre 2018 09:58
> À : [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Oct 2018 14:59:56 +0100

> draft-ietf-softwire-yang relies on an existing registry: : https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6. So, the list cited by Tom is from that registry. draft-ietf-…

It's a long list in section titled:
"Internet-standard MIB - mib-2.interface.ifTable.ifEntry.ifType.tunnelType"

I think it binds the concept of a 'tunnel' to that of an 'interface'.

They are distinct.  Not only there are interfaces that are not tunnels 
but there are tunnels that have no interfaces either.  (i.e. tunnels 
that are not visible in the full list of interfaces of a computer).

This boils down to the YANG model to _not_ see these tunnels either.

Alex

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 14:20:46 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Alexandre Petrescu [mailto:[email-masked]]
> Envoyé : lundi 29 octobre 2018 15:00
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> > draft-ietf-softwire-yang relies on an existing registry: :
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6.
> So, the list cited by Tom is from that registry. draft-ietf-softwire-yang is
> only echoing those values.
> 

[Med] The current registry includes 17 values.  

> that are not visible in the full list of interfaces of a computer).

[Med] If you have any concern with the design, you can raise the point to the authors of RFC4087, RFC8343, and RFC7224.

> This boils down to the YANG model to _not_ see these tunnels either.

[Med] RFC8343 allows to indicate the type of an interface. Supported values are defined in RFC7224. In particular, the type of an interface can be "tunnel". Because tunnel interfaces can be different types, new identities echoing "tunnelType" are derived from "ift:tunnel".  

> 
> Alex
> 
> >
> > If you need a new value or if you have a question about a given interface
> tunnel type, please follow the guidelines in the url cited above. All this is
> out of the scope of draft-ietf-softwire-yang.
> >
> > Cheers,
> > Med
> >

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 29 Oct 2018 15:33:24 +0100

> [Med] If you have any concern with the design, you can raise the point to the authors of RFC4087, RFC8343, and RFC7224.

Thank you for the redirection to authors of 3 RFCs :-)

I do not have a concern with the design.

Alex

---

From: tom petch <[email-masked]>
Date: Tue, 30 Oct 2018 12:07:01 +0000

----- Original Message -----
From: "Alexandre Petrescu" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, October 29, 2018 1:59 PM

> > draft-ietf-softwire-yang relies on an existing registry: :
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbe
rs-6. So, the list cited by Tom is from that registry.
draft-ietf-softwire-yang is only echoing those values.
> "Internet-standard MIB -
mib-2.interface.ifTable.ifEntry.ifType.tunnelType"

Alex

I agree, at least in part; tunnels and interfaces are different animals
and it is unfortunate that they were conflated in SMI.

I was surprised that NETMOD had not produced a YANG module for tunnels
but it seems that there has been no need for the past decade.  That
said, I think that it is a good idea to have one.  Whether or not it
should mirror the Tunnel MIB I find more debatable.

My own homework came across other IP in IP varieties which do not
appear.

Tom Petch

>
> Alex
>
> >
> > If you need a new value or if you have a question about a given
interface tunnel type, please follow the guidelines in the url cited
above. All this is out of the scope of draft-ietf-softwire-yang.
> >>> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6

---

From: tom petch <[email-masked]>
Date: Tue, 30 Oct 2018 12:07:01 +0000

----- Original Message -----
From: <[email-masked]>
To: "Sander Steffann" <[email-masked]>; "tom petch"
<[email-masked]>
Sent: Monday, October 29, 2018 12:08 PM

Hi Sander,

For what we are doing in the draft, we don't need to assign a tunnel
type value for each of them. One single aplusp value is sufficient. We
do have features to cover specificities (map-e, map-t, and lw4o6).

<tp>

True, one single aplusp is enough for you at this point in time but is
it right for the whole of the IETF, now or in future?

My instinct would be to also have MAP-E and MAP-T derived from aplusp
and it seems I am not alone in this.  It takes less effort to get it
right first time instead of having to go back and change things later,
so I think that the question of how many tunnels we should add at this
point in time is a worthwhile discussion.

Tom Petch

Cheers,
Med

> provisioning style and encapsulation/translation, so I'm not sure they
can be
> Lw4over6 [rfc7596]: per-customer mapping between IPv4 and IPv6
addresses,
> MAP-T [rfc7599]: algorithmic mapping between IPv4 and IPv6 addresses,
IPv4
> transported as IPv6 packets using SIIT
>
> Cheers,
> Sander
>

---

From: <[email-masked]>
Date: Tue, 30 Oct 2018 12:50:59 +0000

Hi Tom, 

Please see inline.

Cheers,
Med

> De : tom petch [mailto:[email-masked]]
> Envoyé : mardi 30 octobre 2018 13:07
> À : BOUCADAIR Mohamed TGI/OLN; Sander Steffann
> Cc : 6man WG
> True, one single aplusp is enough for you at this point in time

[Med] Glad to see that we are in agreement. 

 but is
> it right for the whole of the IETF, now or in future?

[Med] New codes can be assigned in the future if there is a need for it. IMHO, it does not make sense to ask for codes that are not used in the specification.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 30 Oct 2018 13:23:55 -0700

> On Oct 30, 2018, at 05:07, tom petch <[email-masked]> wrote:
>> 
> 
> Alex
> 

It’s not entirely obvious to me that netted / netconfig would be where the tunnel models were produced.

They tend if fact to be produced by the tunnel protocol maintainers e.g. l3sm/l2sm/ccamp and so on. The management tools for a product tend to be developed itself in my experience.

> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>